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Capitolo 1 
Introduzione 


Nella seconda metà del secolo scorso la digitalizzazione delle informazioni ha portato 
grandi cambiamenti in tutti i campi, spesso e volentieri migliorando molti aspetti del¬ 
la vita quotidiana e professionale di ognuno di noi, e talvolta creandone di nuovi. Nel 
campo musicale ha permesso infatti la nascita di nuovi generi, nuove modalità di inte¬ 
razione con la musica e più in generale con il suono; sono nati così numerosi software 
audio dalle più disparate applicazioni: dai semplici media player, alle DAW (Digital 
Audio Workstation ) che simulano i banchi di registrazione analogici, agli strumenti 
virtuali che simulano invece strumenti musicali reali. La più recente diffusione ca¬ 
pillare di Internet in tutto il mondo ha portato ad un considerevole aumento della 
fruibilità dei contenuti digitali, rendendoli immediatamente disponibili a chiunque. 
Anche i software audio non sono stati da meno: infatti al giorno d’oggi tutti hanno 
la possibilità di creare musica dal proprio computer, senza dover andare per forza in 
uno studio di registrazione. 

Nel caso particolare degli strumenti virtuali, essi permettono anche a chi non è 
musicista di poter scrivere, ad esempio, una melodia al computer, per poi farla suo¬ 
nare dallo strumento attraverso il computer stesso. D’altra parte, per chi invece è 
musicista, questo è stato un grosso passo avanti dal punto di vista della produzione 
e pre-produzione: nel caso ad esempio di un chitarrista che voglia fissare le proprie 
idee compositive, attraverso l’utilizzo di uno strumento virtuale egli avrebbe modo di 
sentire in anteprima come potrebbe suonare quello reale una volta registrato; inoltre, 
avendo a disposizione altri strumenti virtuali, potrebbe da solo scrivere le parti per 
un intero gruppo e sentirle suonare, senza dover coinvolgere altri musicisti. Questo e 
molti altri vantaggi hanno portato alla diffusione commerciale degli strumenti virtuali 
e dei software musicali in generale. 
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Con questi presupposti, il presente elaborato descrive il tirocinio svolto presso 
Chocolate Audio di Sirnone Coen, azienda che si occupa appunto della realizzazione 
di librerie di suoni digitali (sa rupie libraries ) e strumenti virtuali in grado di ripro¬ 
durre questi suoni. 

Uno strumento virtuale (in inglese Virtual instrument, o abbreviato V.I.) è un sinte¬ 
tizzatore digitale, cioè un software capace di generare audio. L’audio generato può 
essere totalmente sintetizzato dal software (caso in cui di solito lo strumento viene 
chiamato semplicemente syntli), oppure, come anticipato, può essere la versione digi¬ 
talizzata di uno strumento musicale esistente. In quest’ultimo caso si rende necessaria 
la digitalizzazione dei possibili suoni che un certo strumento può generare, in modo 
da poterli poi riprodurre tramite il software; l’insieme di questi suoni prende il nome 
di sample library. Talvolta questo termine viene utilizzato per indicare lo strumento 
e la libreria insieme. La tendenza attuale in quest’ambito è quella di creare strumenti 
virtuali più realistici possibile, cercando di catturare tutte le varietà sonore e tim¬ 
briche che il vero strumento può assumere. Di conseguenza le sample library stanno 
diventando sempre più onerose dal punto di vista dello spazio occupato in memoria. 

Chocolate Audio sviluppa principalmente strumenti per Kontakt, un campiona¬ 
tore software di Native Instruments che offre agli utenti la possibilità di poter pro¬ 
grammare i propri V.I. tramite un linguaggio script proprietario, oppure ovviamente 
di utilizzare strumenti di terze parti. Un motore interno si occupa di gestire le in¬ 
formazioni a livello macchina, così l’utente non deve preoccuparsi di come vengono 
utilizzate le risorse. Quest’approccio consente anche a chi non è uno sviluppatore di 
creare strumenti virtuali, poiché ci sono molti software e materiale di aiuto sull’ar¬ 
gomento, essendo Kontakt molto diffuso e popolare. Tuttavia le possibilità di azione 
sono limitate dal motore sul quale si eseguono gli script, il cui codice non è modifica¬ 
bile e al quale bisogna adattarsi. 

Da qui l’esigenza dell’azienda di sviluppare uno strumento indipendente da Kontakt, 
unendo all’alta qualità delle riprese audio un motore dalle funzionalità pienamente 
controllabili. 


1.1 Obiettivi del progetto 

Il tirocinio dunque, iniziato nel mese di ottobre 2018 e durato circa 4 mesi, ha avuto 
come scopo lo sviluppo di un strumento virtuale con suoni di batterie acustiche, gestiti 
da un motore proprietario creato ad hoc. 

Le caratteristiche dello strumento sono state individuate dall’azienda, che ha fornito 
le specifiche generali da seguire durante il lavoro; successivamente, con l’aiuto esterno 
di un esperto sviluppatore (Luca Capozzi di Audiority), è stato fatto uno studio di 
fattibilità del progetto con relativa analisi delle specifiche e pianificazione delle attività 
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da svolgere. Durante lo studio ci si è focalizzati sulla priorità del motore audio (audio 
erigine) a discapito dell’interfaccia grafica (GUI - Graphical User Interface), la quale 
è stata sviluppata nell’ultima parte del tirocinio. Nella GUI sono state implementate 
solo le funzionalità di base, in modo da non togliere tempo prezioso allo sviluppo del 
motore del programma, e soprattutto per impedire che eventuali problemi nel motore 
fossero erroneamente attribuiti a essa, o viceversa che errori nella GUI potessero essere 
attribuiti al motore. 

La scelta del mezzo effettivo per lo sviluppo del programma è ricaduta sul fra- 
mework JUCE, appositamente pensato per la programmazione di software audio e 
scritto in linguaggio C++. JUCE permette di avere a disposizione un set di strumen¬ 
ti (classi e metodi) che semplificano notevolmente lo sviluppo di applicazioni audio, 
e in alcuni casi basta utilizzare questi così come vengono forniti dal framework per 
riuscire a compilare un programma funzionante. In altri casi più complessi, come 
il suddetto, sarà necessario modificare le funzionalità del framework per riuscire nei 
propri intenti. JLICE sarà meglio approfondito nel prossimo capitolo, dove verranno 
analizzate nel dettaglio le tecnologie utilizzate. 



Capitolo 2 

Cenni preliminari 


2.1 Tecnologie utilizzate 

In questo capitolo verrà fatta una panoramica sulle tecnologie e le conoscenze coinvolte 
nel tirocinio. Fatta eccezione per il linguaggio C++, tutte le altre sono state pensate 
e sviluppate appositamente per l’audio e/o per la musica. 

2.1.1 CH—b nello sviluppo di plugin audio 

Nel 1983 Bjarne Stroustrup sviluppa quello che negli anni seguenti diventerà uno dei 5 
linguaggi di programmazione più utilizzati al mondo. C++ nasce come potenziamento 
del linguaggio C, da cui prende il nome, e si basa sul paradigma della programmazione 
orientata agli oggetti, paradigma che consente di avere un livello di astrazione tale da 
realizzare progetti di grosse dimensioni. C++ trova applicazione in svariati campi: lo 
si trova ad esempio nelle applicazioni real-time o mobile, nei componenti per sistemi 
operativi, nei videogame, nei software di grafica o musicali e molto altro. 

Da notare che, a differenza di linguaggi più moderni, in C++ (anche nelle sue 
versioni più recenti) non è presente la concezione di audio vero e proprio, nel senso 
che non esistono classi o metodi predefiniti per la sua gestione; esso viene invece rap¬ 
presentato come una sequenza di numeri (detti campioni, in inglese samples ), ognuno 
dei quali viene messo in una coda denominata buffer per poi essere riprodotti sotto 
forma di suono dalla periferica audio (questo è l’approccio generale dell’audio digitale, 
e quindi anche del C++). Dal punto di vista della macchina dunque, il suono non è 
altro che un insieme di campioni il cui valore numerico rappresenta l’ampiezza istan¬ 
tanea dei campioni stessi. Quando un computer vuole produrre dell’audio, il buffer di 
uscita viene inviato alla scheda audio raggruppato in blocchi di campioni: appena un 
blocco è stato riempito viene passato per intero alla scheda, la quale converte l’audio 
in forma analogica e lo passa agli speaker. In questo senso l’audio percepito prodotto 
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da un sistema digitale si può immaginare come una sequenza di blocchi di campioni 
che la scheda preleva dal buffer continuamente. Nel caso il buffer sia vuoto (cioè tutti 
i campioni valgono zero) la scheda continuerà comunque a prelevare i blocchi e sarà 
generato del silenzio. La responsabilità di produrre i campioni è delegata quindi al 
software audio, il quale riempirà il buffer quando necessario; questo tipo di approccio 
è chiamato push e, a differenza della sua controparte pulì - in cui i blocchi sono ge¬ 
nerati dietro richiesta del sistema operativo - richiede minori tempi di elaborazione. 

I software audio come gli strumenti virtuali possono funzionare da soli ( slancialo- 
ne), caso in cui il buffer di uscita viene passato direttamente alla scheda audio per 
essere riprodotto, oppure possono essere programmati in modo da essere ” ospitati” 
all’interno di altri software, chiamati host. Quando un software viene configurato in 
questo modo, esso prende il nome di plughi. Un plughi generalmente è un software 
che aggiunge funzionalità ad un host, potenziandone le capacità. Nel caso del plughi 
audio, anziché alla scheda, questo passa il buffer all’host (generalmente una DAW) il 
quale si occupa poi di mandarlo al driver della periferica audio. Vista la sua natura, 
il plughi dev’essere configurato in modo da adattarsi all’host, altrimenti potrebbero 
sorgere nei problemi nella riproduzione, o peggio ancora potrebbe anche non avviarsi. 

L’host ha il compito di, oltre che passare l’audio in uscita dal plughi, inoltrare 
ad esso le informazioni in ingresso. Queste informazioni possono essere di tipo audio 
(come nel caso dei Litri, ad esempio un equalizzatore) oppure di tipo binario, come 
nel caso del MIDI, descritto nella prossima sezione. 

2.1.2 Lo standard MIDI 

MIDI (Musical Instrument Digital Interface) è un protocollo sviluppato negli anni 
ottanta che permette l’interazione tra dispositivi musicali, siano essi strumenti elet¬ 
tronici o computer. Grazie a questo standard, sviluppato e adottato sin da subito dai 
maggiori costruttori di strumenti elettronici, è stato possibile mettere in comunicazio¬ 
ne dispositivi di diversa natura e fabbricazione, ovviando così ai problemi di intero- 
perabilità dovuti a standard proprietari e rivoluzionando l’interazione con la musica. 

II protocollo funziona attraverso un’interfaccia hardware dedicata (oggi anche tra¬ 
mite USB), dalla quale passano messaggi - detti messaggi MIDI - che descrivono il 
comportamento dello strumento (ad esempio quale nota dev’essere suonata in un cer¬ 
to istante). I messaggi MIDI quindi non generano propriamente il suono, ma più 
semplicemente servono per fornire al dispositivo indicazioni su ciò che deve fare (che 
sia generare un suono o modificarne un parametro). Questo consente al protocollo 
di essere poco oneroso in termini di spazio in memoria, poiché bastano pochi byte 
per rappresentare un messaggio. Grazie a ciò, e anche per merito della sua praticità 
di utilizzo, MIDI si è diffuso in tutto il mondo come standard per la comunicazione 
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musicale e, nonostante la sua obsolescenza, è ancora largamente utilizzato in que¬ 
st’ambito, pur non essendo praticamente mai stato aggiornato nel corso degli anni. 
Recentemente è stato annunciato MIDI 2.0, tutt’ora in fase di prototipazione, che 
implementa alcune funzionalità più al passo coi tempi (come raggiunta del supporto 
per i tablet, o l’interazione in rete tra dispositivi). 

Per fornire un contesto più pratico, si può immaginare la comunicazione tra due 
dispositivi collegati tramite questa interfaccia, ad esempio una tastiera MIDI ed un 
computer con un synth digitale installato: la tastiera, in seguito alla pressione di un 
tasto, manderà in uscita un messaggio contenente l’informazione su quale tasto è sta¬ 
to premuto e con quale intensità; il computer, alla ricezione del messaggio, produrrà 
la nota corrispondente attraverso il synth, facendola sentire tramite gli altoparlanti 
collegati alla scheda audio. Ovviamente tutto ciò deve accadere in pochi millisecondi, 
altrimenti saranno percepiti dei ritardi nella riproduzione delle note che renderebbero 
l’esperienza molto frustrante se non del tutto impraticabile. Fortunatamente tutto 
questo viene evitato grazie alla leggerezza dei messaggi, che richiedono due, massimo 
tre byte di spazio (potrebbero esserci comunque dei ritardi causati dai tempi di proces- 
samento del computer). Possiamo quindi affermare di essere in un contesto real-time, 
dove la velocità di elaborazione delle informazioni ricopre un ruolo fondamentale. 
Un’altra importante caratteristica del protocollo, che rende ininfluente questo aspet¬ 
to, è quella di poter scrivere direttamente al computer una sequenza di eventi MIDI, 
senza che effettivamente la si debba suonare tramite un dispositivo esterno. La se¬ 
quenza scritta (come del resto quella suonata) può poi essere modificata a piacimento, 
fornendo un livello di controllo totale sull’esecuzione. 

Esistono diversi tipi di messaggio MIDI e ogni tipo controlla un aspetto differen¬ 
te dell’interazione, come ad esempio il controllo dei parametri che caratterizzano 
un suono, o la selezione dello strumento da utilizzare. Di seguito verranno ap¬ 
profonditi solo due tipi di messaggio, poiché sono gli unici interessati nel conte¬ 
sto. Il messaggio che permette di far suonare una nota prende il nome di ’Note 
OiT e come anticipato, viene inviato alla pressione del tasto sul dispositivo; vice¬ 
versa il messaggio ’Note Off’ serve per bloccare la riproduzione della nota e vie¬ 
ne inviato al rilascio del tasto. Tutti e due i messaggi sono formati da uno sta¬ 
tus byte, che ne identifica il tipo, e due data byte con l’informazione vera e pro¬ 
pria: il primo rappresenta la nota da suonare (o da fermare) e il secondo l’inten¬ 
sità da attribuire alla nota detta velocity e rappresentata con valori interi da 0 a 
127. Ovviamente nel caso del Note Off, l’informazione sulla velocity risulta scontata 
poiché per definizione essa dev’essere nulla; spesso infatti questo tipo di messag¬ 
gio può essere del tutto evitato utilizzando dei Note On con velocity uguale a zero. 
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Nel plughi oggetto di questo elaborato, come si vedrà meglio nel seguito, i messaggi 
di tipo Note On innescano la riproduzione del suono associato ad una data nota, 
mentre i Note Off vengono pressoché ignorati vista la natura dei suoni di batteria, i 
quali hanno durata relativamente breve e devono essere riprodotti nella loro interezza 
(si ricorda che si vuole simulare il comportamento di una batteria acustica, quindi 
terminare prematuramente un suono risulterebbe innaturale). 

2.2 II framework JUCE 

Le tecnologie viste fin’ora sono sufficienti per sviluppare un’applicazione audio qualsia¬ 
si, a patto ovviamente di averne la padronanza. Tuttavia, specialmente per software 
complessi, è utile avere un aiuto esterno che velocizzi e faciliti il processo di sviluppo, 
fornendo un’infrastruttura che si interpone tra il sistema operativo e il programmato- 
re, con albinterno dei costrutti già pronti da utilizzare. Questo aiuto, nello sviluppo 
software in generale, è dato dal framework. 

LIn framework è un architettura logica formata da classi astratte e da relazioni tra 
di esse; le classi astratte, contenute in delle librerie, forniscono una base di partenza 
per l’impementazione di quelle concrete, a seconda degli scopi del progetto. Questo 
risparmia al programmatore la stesura di ampie porzioni di codice "generico”, la¬ 
sciandogli il compito di scrivere solo il contenuto vero e proprio del programma. Il 
framework inoltre fornisce utili strumenti di supporto come le IDE (Integrateci Deve- 
lopment Environment) o il debugger per la risoluzione dei problemi. 

Come anticipato nell’introduzione, per questo progetto è stato utilizzato 
JUCE (Jules Utility Class Extension), un framework multipiattaforma parzialmente 
open-source scritto in C++. Sviluppato originariamente da Julian Storer nel 2004, 
offre una serie di librerie (moduli) per agevolare lo sviluppo di applicazioni desktop o 
mobile, e viene utilizzato soprattutto per plughi e GUI. Oltre ai moduli, JUCE mette 
a disposizione Projucer, un’IDE per la creazione e la gestione dei progetti. Trami¬ 
te Projucer è possibile configurare le parti generali del progetto, per poi esportarlo 
sull’IDE di riferimento a seconda del sistema operativo utilizzato ( Visual Studio su 
Windows, Xcode su maeOS, CodeBlocks su Linux). Ciò permette di avere lo stesso 
codice su sistemi operativi diversi, delegando al framework la responsabilità di in- 
terfacciarsi con essi. Le modifiche al codice vero e proprio vengono fatte albinterno 
dcllTDE di riferimento, che a differenza di Projucer consente una migliore gestione 
degli errori, e in ogni caso fornisce un ambiente di sviluppo più completo. Durante il 
tirocinio è stato utilizzato Visual Studio 2017, dunque per semplicità espositiva d’ora 
in poi verrà dato per scontato come IDE di riferimento (o exporter nel linguaggio del 
Projucer). 
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Nel framework sono presenti delle asserzioni sparse nel codice che servono duran¬ 
te il debug. In questo modo Visual Studio interromperà l’esecuzione del program¬ 
ma se qualche risorsa viene utilizzata in modo sbagliato: ad esempio se si cerca 
di utilizzare un puntatore senza prima inizializzarlo (come mostrato nella hgura 
sotto) verrà generato un punto d’interruzione nel codice, altrimenti il programma 
potrebbe assumere un comportamento inaspettato provocando danni al sistema. 


4- 99 

previousMasterGain = *masterLevel; 

® 

100 



101 

auto lastSampleRate = sampleRate; 

Eccezione generata ? X 

102 



103 

String message; 

É stata generata un'eccezione: violazione di accesso in lettura. 

104 

message << "Preparing to play audio 

this->masterLevel era nullptr. 

105 

message << " samplesPerBlock = " << 


106 

message << " sampleRate = " << samp 


107 

Logger : : getCurrentLogger ()- >writeTo 


108 


Copia dettagli 

109 

B for (auto midiChannel = 0; midiChan 

A Impostazioni eccezioni 

110 

: { 

0 Interrompi quando viene generato questo tipo di eccezione 

111 

if (outputs[midiChannel] != "Em 

Eccetto quando generato da: 

112 

synth[midiChannel]->setCurr 

□ DrumSampler.vst3 

113 

else break; 

Apri impostazione eccezione | Modifica condizioni , 

114 

} 

.n: 

115 

[} 



Figura 1: Esempio di eccezione generata da Visual Studio 


Quando si avvia il Projucer, è possibile scegliere il tipo di progetto, come applica¬ 
zione standalone, plughi, programma console e così via. Una volta scelto il template 
(nel nostro caso il plughi) è possibile scegliere gli exporter con cui si desidera espor¬ 
tare il progetto ed il suo nome, dal quale dipenderanno i nomi delle classi principali 
create automaticamente. Dopo questo passo vengono generati i file che contengono il 
nucleo ”grezzo” del plughi, denominati PluginProcessor. epp e PluginEditor. epp 
(con annessi header). I file contengono l’implementazione base delle due classi prin¬ 
cipali del plugin, rispettivamente AudioProcessor e AudioProcessorEditor. In 
queste due classi viene fornito il set di strumenti (metodi, enumerazioni e quan- 
t’altro) per interagire con il processore audio (chiamato semplicemente processore 
d’ora in poi, da non confondere con la CPU) e l’interfaccia grafica. In realtà le 
classi effettivamente utilizzate nel plugin sono ereditate da queste due (Projucer 
genera automaticamente le classi derivate). Nelle classi base sono presenti alcu¬ 
ni metodi contenenti già del codice predisposto, i quali sono ereditati nella classe 
dell’utente, altri metodi hanno invece valore impostato a 0 e sono detti astratti 
o virtuali puri. Secondo le regole del C++ per questi ultimi è necessario esegui¬ 
re il cosiddetto override del metodo se si vuole ereditare la classe (volendo è pos¬ 
sibile eseguirlo anche sugli altri, ma per quelli astratti è obbligatorio). Il Proju¬ 
cer fortunatamente inserisce già questi metodi nelle classi derivate con l’etichetta 
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override, lasciando all’utente il compito di riempire le funzioni col proprio codice. 
Nelle impostazioni di Projucer è possibile configurare gli aspetti generali del progetto, 
come il nome, la versione, i formati col quale si vuole compilare il plughi (che verranno 
discussi nel seguito) e così via. Significativo è il campo ’Plugin Characteristics’ che 
consente di impostare dei flag riguardanti appunto le caratteristiche del plughi, come 
il fatto che esso sia un synth o no, o che riceva segnali MIDI in ingresso e/o in uscita. 
Una volta scelto il necessario, si è pronti a esportare il progetto: Projucer genera un 
programma, o meglio il suo scheletro, che è già compilabilc da Visual Studio, il quale 
a sua volta può subito creare il file eseguibile. Ovviamente ancora non è presente nes¬ 
sun operazione sull’audio tantomeno sulla GUI, però ciò consente allo sviluppatore 
di avere a disposizione un’anteprima dcll’effetto che avrà il proprio codice sul plughi 
man mano che il lavoro va avanti. 

Un altro strumento utile fornito da JUCE è l’ AudioPluginHost, un programma 
che simula un host - ma molto più leggero delle normali DAW - con il quale è possi¬ 
bile ad esempio fornire un input audio e/o MIDI al plughi (è presente un generatore 
di onda sinusoidale, e una tastiera MIDI virtuale con la quale si possono mandare 
i messaggi) oppure inviare l’audio dal plughi all’uscita generale. Quando si avvia 
il programma in modalità debug, Visual Studio può essere configurato in modo da 
aprire in automatico AudioPluginHost, attraverso il quale può eseguire il plughi. 


2.2.1 Esempio: un synth che genera rumore 

Qui di seguito viene fornito un semplice esempio di synth implementato con JUCE. 
Il synth genera del rumore bianco attraverso una funzione che crea numeri casuali, 
il cui valore viene attribuito ai campioni del buffer. Nel codice viene riportato solo 
il metodo (appartenente alla classe derivata da AudioProcessor) che gestisce il ren¬ 
dering dei blocchi di campioni, chiamato processBlockO, essendo l’unico sul quale 
si effettuano modifiche in questo caso. All’interno di esso viene creato un ciclo che 
itera nei canali in uscita [1] (nella maggioranza dei casi si avranno uno o due canali). 
Per ognuno di essi viene preso il puntatore al primo campione del blocco e salvato 
nel puntatore output [2], In seguito il buffer viene riempito con un numero casuale 
generato dal metodo nextFloatO, appartenente alla classe Randora di JUCE [3]. Il 
valore restituito dal metodo può assumere qualsiasi valore tra 0 e 1, perciò i valori 
prima di essere salvati nel buffer vengono normalizzati con un’amplificazione (molti¬ 
plicando per 0,25) seguita da una scalatura del range (sottraendo 0,125). In questo 
modo si avranno valori tra -0,125 e +0,125, visto che non sono presenti controlli per 
regolare l’intensità del suono prodotto. 
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// in PluginProcessor.cpp 


void MyAudioProcessor::processBlock 
{ 


(AudioSampleBuffer& buffer, 
MidiBuffer& midiMessages) 


for (int channel = 0; channel < buffer.getNumChannelsO; ++channel) 
float* output = buffer.getWritePointer(channel); 
for(int sample = 0; sample < buffer.getNumSamples(); sample++) 
output[sample] = random.nextFloat() * 0.25f - 0.125f; 

> 


> 


{ // [ 1 ] 
// [ 2 ] 

// [3] 


// in PluginProcessor .h 

private : 

Random random; 


2.3 Formati di esportazione 

I plughi audio sono distrubuiti in diversi formati file, a seconda dcH’host in cui ven¬ 
gono caricati. Per poter compilare il progetto nei diversi formati, è necessario avere 
i corretti SDK - Software Development Kit. Qui di seguito verranno brevemente 
descritti i formati richiesti nelle specifiche del plughi. 

2.3.1 VST (Virtual Studio Technology) 

Sviluppata da Steinberg nel 1996 originariamente per la DAW Cubase, VST è stato 
il primo formato per i plugin software ed è ormai diventato uno standard per i plughi 
audio. Esso infatti è supportato da praticamente tutti gli host e i sistemi operativi 
in circolazione, ed è il formato di riferimento sul quale è stato sviluppato e testato 
questo progetto. Inizialmente i VST erano semplici effetti audio come riverberi o 
stereo panner, nel corso degli anni sono state rilasciate due versioni aggiornate: 

• VST2, rilasciata nel 1999, vide tra le altre aggiunte la capacità di ricevere in 
ingresso messaggi MIDI; questo permise la nascita del formato VSTi - Vir¬ 
tual Studio Technology Instrument. I VSTi possono essere dei synth o dei 
campionatori. 
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• VST3 rilasciata nel 2008, nel quale sono stati implementati multipli ingressi e 
uscite MIDI, e ingressi audio per i VSTi. Altri aggiornamenti successivi hanno 
migliorato la flessibilità e la naturalezza dell’esecuzione musicale. 

Nel 2013 Steinberg ha smesso di aggiornare e distribuire SDK per VST2, i quali 
sono stati integrati all’interno di quelli per VST3 per questioni di retrocompatibilità. 
Più recentemente, a fine 2018, Steinberg ha annunciato anche la rimozione di questi, 
rendendone il reperimento Online pressoché impossibile, di conseguenza anche JUCE 
ha rimosso i riferimenti dal framework. Fortunatamente per il plughi in questione gli 
SDK necessari sono stati scaricati appena prima che ciò accadesse. 

2.3.2 AU (Audio Units) 

Le Audio Units sono l’architettura plughi di Apple e sono fornite da Core Audio, 
l’interfaccia a basso livello che si occupa di gestire l’audio nei sistemi macOS e iOS. 
Possono essere pensate come l’alternativa di Apple allo standard VST. ALI imple¬ 
menta alcune caratteristiche interessanti come il timestretch e lo streaming su rete, e 
viene utilizzato negli host sviluppati per macOS, come Logic Pro, GarageBand, Final 
Cut Pro, Ableton Live, /?caper e così via. 

2.3.3 AAX (Avid Audio eXtension) 

Come per le Audio LInits, anche l’azienda Avid ha sviluppato il proprio formato plughi 
per i suoi software audio/video. Esso viene utilizzato in particolare nella DAW Pro 
Tools dalla versione 11 in poi. Con AAX, Avid ha aggiornato il suo vecchio formato 
RTAS, acronimo di Reai Time Audio Suite, funzionante sulle versioni di Pro Tools 
precedenti alla 11. 



Capitolo 3 

Il plugin Drum Sampler 


Il plugin oggetto di questo elaborato è chiamato ’ Drum Sampler’ e, come suggerito 
dal titolo, si tratta di uno strumento virtuale in grado di riprodurre suoni di batte¬ 
rie acustiche. I suoni che formano la sample library erano già stati acquisiti prima 
dcH’inizio del tirocinio, per cui il lavoro ha interessato in gran parte la stesura del 
codice necessario alla loro corretta riproduzione/gestione e in minima parte l’inter¬ 
faccia grafica per controllarne i parametri. In questa sezione verrà fornita una breve 
descrizione delle caratteristiche generali del programma, mentre nel resto del capitolo 
saranno analizzate nel dettaglio le classi e i metodi che coprono ruoli di rilievo nel suo 
funzionamento. Da notare che la seguente è una divisione logica delle funzionalità 
del plugin: in realtà queste sono sparse nelle varie classi e non c’è una vera e propria 
separazione nel codice. 

3.1 Descrizione generale 

3.1.1 II motore audio 

È il cuore del plugin e ne controlla gli aspetti basilari. Nel Projucer sono attivati i 
fìag ’Plugin is a Synth’ e ’Plugin MIDI Input’ sotto il campo Plugin Characteristics, 
e i fìag che indicano i formati che si vuole esportare sotto il campo ’Plugin Formats’ 
ovvero ‘VST (Legacy)’, ‘VST3’, ‘AU’ e ‘AAX’. Il plugin non necessita di ingressi 
audio e di uscite MIDI. I fìag hanno l’effetto di impostare a true i valori booleani 
corrispondenti all’interno del codice: in questo sono presenti istruzioni di compilazione 
condizionale a seconda dei valori scelti, o metodi che possono restituire questi valori 
durante l’esecuzione. 

Nel file PluginProcessor. epp vengono chiamati i metodi createPluginFilter () e 
createEditor () che allocano in memoria lo spazio necessario per i rispettivi oggetti 
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attraverso l’operatore new. Qui avviene la creazione vera e propria del processore e 
della GUI: 


// PluginProcessor.cpp 

AudioProcessor* JUCE_CALLTYPE createPluginFilter() 

{ 

return new DrumProcessor(); 

> 

AudioProcessorEditor* DrumProcessor::createEditor() 
{ 

return new DrumEditor (*this , parameters); 

> 


La classe principale è DrumProcessor, derivata da AudioProcessor, nella quale ven¬ 
gono gestiti tutti gli aspetti principali del plughi, come la creazione dei parametri 
e dei canali del mixer, l’impostazione della frequenza di campionamento corretta in 
base all’host, la gestione generale dell’audio in uscita e il salvataggio degli stati del 
plughi. Esso ha 8 uscite stereo separate che consentono di poter mandare l’audio 
di un singolo canale (che corrisponde ad un elemento della batteria) ad una traccia 
differente sulla DAW, in modo da poter mixare separatamente l’audio proveniente dai 
diversi elementi. 

Ad un livello pratico, il processore crea più oggetti di tipo DrumSynth, ognuno rappre¬ 
sentante un canale. In questa classe, derivata da Synthesiser, sono creati i suoni e le 
voci che li riprodurranno. Anche le classi che rappresentano questi sono derivate dal 
framework. Una SynthesiserVoice può riprodurre uno o più SynthesiserSound, 
per cui DrumSound è la classe che attua il caricamento dei file in memoria, mentre 
a DrumVoice è delegata la gestione logica dei suoni e il rendering vero e proprio dei 
campioni. Essi vengono passati al processore in blocchi dopo aver applicato il tuning 
(se attivato). 

3.1.2 Mappatura MIDI 

Nel synth e nelle sue sottoclassi viene gestita la mappatura dei messaggi MIDI pas¬ 
sati dal processore, che a sua volta li riceve dal MidiBuffer esterno. I messaggi in 
arrivo vengono cosi scandagliati e solo quelli di Note On intercettati, consentendo la 
chiamata del metodo noteOnO che trova una voce libera e la usa per riprodurre il 
suono corrispondente. Solitamente i campionatori di batteria più basilari fanno cor¬ 
rispondere alla velocity del Note On un volume equivalente in uscita. Questo rende il 
suono risultante molto innaturale e più adatto ad applicazioni in musica elettronica. 
Se si vuole simulare efficacemente uno strumento musicale bisogna adottare la tecnica 
multisample , che associa ad una certa velocity un certo suono senza modificarne il 
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volume. L’intensità del suono innescato dipenderà dall’esecuzione ripresa a monte in 
studio di registrazione. Per ogni pezzo della batteria quindi, vengono registrate più 
esecuzioni suonate a diverso volume e con diverse articolazioni (ad esempio un colpo 
di ’rimshot’ sul rullante suonato alla massima potenza, o un colpo secco e leggero al 
centro della pelle). Il valori di velocity vengono suddivisi in range ai quali viene asse¬ 
gnato ogni suono, così da rendere più naturali sia la simulazione dell’audio rislutante, 
sia il feeling in esecuzione qualora il plughi venga usato con una batteria elettronica. 
Per ora il plughi si configura con un approccio mono-trigger, ovvero si utilizza solo 
l’articolazione di base (Hit) per ogni pezzo. Le articolazioni speciali come ad esempio 
i rimshot, o gli stessi campioni però suonati con le spazzole e così via, verranno invece 
gestite in futuro. 

3.1.3 Interfaccia grafica 

La GUI è gestita dalla classe DrumEditor, derivata da AudioProcessorEditor. Nel- 
l’editor sono stati implementati per ora solo gli 8 canali c il canale master, con relativi 
controlli di volume, pan e le relative etichette descrittive, i pulsanti ’Mute’, ’Solo’ e 
’Learn’. L’interfaccia è molto basica e fornisce solo i controlli per i parametri base: 



Figura 2: L’interfaccia grafica del plugin 
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Come si può notare, solo i primi due canali e il master sono attivi. Per ora, a fini di 
testing, sono più che sufficienti. 


3.2 La classe DrumProcessor 

In questa sezione verrà analizzata nel dettaglio la classe principale del plughi, imple¬ 
mentata nel file PluginProcessor. cpp e nello header corrispondente. Per prima cosa 
nello header viene definito maxMidiChannel = 8 all’interno di un enumerazione, che 
verrà utilizzato in vari metodi all’interno del programma. Nello header sono presenti 
le dichiarazioni dei vari metodi sia di default che custom, e le dichiarazioni degli ogget¬ 
ti e delle variabili richieste. Alcuni metodi sono già implementati nello header poiché 
richiedono poche righe di codice, in modo da non creare confusione nel file sorgente. 
Quelli generati dal Projucer sono ad esempio metodi booleani come hasEditorO e 
acceptsMidi(), impostati a true, o pruducesMidi() e isMidiEffect() impostati 
a false. I metodi canAddBusO e canReraoveBus () impediscono agli input di essere 
modificati e agli output di essere aggiunti oltre il valore di maxMidiChannel, o rimossi 
completamente, dunque il numero dei canali può variare da 1 a 8. Questi ultimi due 
sono stati modificati con codice tratto dal tutoria! del sito ufficiale di JUCE: 

// PluginProcessor. h 

bool canAddBus (bool islnput) const override 

{ 

return (!islnput kk getBusCount (false) < maxMidiChannel); 

} 

bool canRemoveBus (bool islnput) const override 

{ 

return (!islnput kk getBusCount (false) > 1); 

> 


Sempre nello header, sono presenti poi tre metodi creati ad hoc, setMutingEnabledO 
e setSoloEnabledO che servono per attivare i rispettivi parametri di Mute e Solo, 
e setLearnFromMidi() che fa entrare il plugin nello stato di ’MIDI Learn’. Esso 
consente di assegnare ad ogni canale un’unica nota con la quale riprodurre i suoni 
associati al canale, in modo da poter mappare agevolmente i suoni su qualunque 
dispositivo MIDI si desideri. 
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Il PluginProcessor. h 

//Un valore negativo per index innesca il canale Master 
void setMuteEnabled(const bool shouldBeEnabled, int index) 
{ 

if (index >= 0) 

isChannelMuteEnabled[index] = shouldBeEnabled; 
else 

isMasterMuteEnabled = shouldBeEnabled; 

> 

void setSoloEnabled(const bool shouldBeEnabled, int index) 
{ 

if (index >= 0) 

isChannelSoloEnabled[index] = shouldBeEnabled; 

} 

// Fa in modo che il synth si metta in attesa di un noteOn 
void setLearnFromMidi (bool isLearnSet, int channel) 

{ 

synth[channel]->isMidiLearning = isLearnSet; 

> 


Viene poi definito un array di stringhe denominato outputs [maxMidiChannel], con 
all’interno i nomi dei canali ( ”Kick”, ”Snare”...) che provvisoriamente viene usato nel 
programma per gestire i canali da attivare. Questo per agevolare il testing, in modo 
da non dover controllare tutti i canali durante il debug. Il plugin è strutturato in 
modo da agire su multiple istanze dei canali, il cui numero dipende dai nomi inseriti 
in questo array. Nel caso la stringa letta nel vettore sia ” Empty ”, i canali non ver¬ 
ranno creati, come si vedrà in seguito. Segue poi la dichiarazione dell’array dei synth 
e una serie di oggetti e puntatori utilizzati nel file sorgente. In questo file, prima del 
costruttore, vengono inizializzate le uscite (di cui solo la prima è attiva di default) [1] 
e l’oggetto AudioProcessorValueTreeState chiamato parameters [2], una struttura 
ad albero che mantiene memoria degli stati del plugin, nella quale andranno salvati 
i parametri. Di default bisogna fornire anche un oggetto UndoManager che consente 
l’annullamento delle modifiche. 

Nel costruttore vengono quindi creati i canali attraverso la creazione di nuovi ogget¬ 
ti DrumSynth [3], poi aggiunti i parametri [4] e collegati ai puntatori effettivamente 
utilizzati dal processore [5]. L’ultima chiamata crea un oggetto ValueTree ed un 
identificatore, che viene passato a parameters [6]. Essa dev’essere effettuata dopo la 
creazione di tutti parametri, altrimenti verrà generata un’eccezione dal debugger. 
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// PluginProcessor.cpp 

DrumProcessor::DrumProcessor() 

: AudioProcessor (BusesProperties() 


.withOutput 

("Output 

#1", 

AudioChannelSet: 

: stereo(), 

true) // [1] 

.withOutput 

("Output 

#2", 

AudioChannelSet: 

: stereo(), 

false) 

.withOutput 

("Output 

#3", 

AudioChannelSet: 

: stereo(), 

false) 

.withOutput 

("Output 

#4", 

AudioChannelSet: 

: stereo(), 

false) 

.withOutput 

("Output 

#5", 

AudioChannelSet: 

: stereo(), 

false) 

.withOutput 

("Output 

#6", 

AudioChannelSet: 

: stereo(), 

false) 

.withOutput 

("Output 

#7", 

AudioChannelSet: 

: stereo(), 

false) 

.withOutput 

("Output 

#8", 

AudioChannelSet: 

: stereo(), 

false) ), 

parameters (*this , &undoManager) // 

[2] 




for (auto channel = 0; channel < maxMidiChannel; channel++) 

{ 

if (outputs[channel] != "Empty") { 

synth. add(new DrumSynth(outputs[channel])); // [3] 

createParameters(parameters, channel); // [4] 

attachParameters(channel); // [5] 

// Inizializza muto e solo come disattivati 
isChannelMuteEnabled[channel] = false; 
isSoloEnabled[channel] = false; 

> 


else break; 

> 

parameters.state = ValueTree(Identifier("DrumSamplerAPVTS")) ; // [6] 


3.2.1 II metodo prepareToPlay() 

Una volta inizializzata la classe nel costruttore, il plugin è quasi pronto a generare au¬ 
dio. Appena prima che ciò accada, viene effettuata la chiamata a prepareToPlayO, 
un metodo che serve principalmente a impostare (nel primo ciclo [1]) la corret¬ 
ta frequenza di campionamento (in arrivo dall’host) per ogni synth. Essendo un 
metodo astratto, dev’essere eseguito l’override. L’altro ciclo for serve invece per 
collegare i livelli dei canali ai rispettivi previousGain [2]. Questi valori verranno 
usati nel processBlockO per creare delle rampe di volume tra il previousGain e 
il currentGain di ogni canale, in modo da rendere i cambi di volume più linea¬ 
ri quando si muove un controllo ( slider ), altrimenti potrebbero sorgere dei distur¬ 
bi nell’audio generato. La medesima cosa viene fatta per il canale master [3]. 
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Il PluginProcessor.cpp 

void DrumProcessor::prepareToPlay (doublé sampleRate, int samplesPerBlock) 

{ 

auto lastSampleRate = sampleRate; // copia frequenza di campionamento 
for (auto midiChannel = 0; midiChannel < maxMidiChannel; ++midiChannel) 

{ 

if (outputs[midiChannel] != "Empty") 

synth[midiChannel]->setCurrentPlaybackSampleRate(lastSampleRate); // [1] 
else break; 

> 

for (auto channel = 0; channel < maxMidiChannel; channel++) 

{ 

if (outputs[channel] != "Empty") 

previousChannelGain[channel] = *level[channel]; // [2] 

} 

previousMasterGain = *masterLevel; // [3] 


3.2.2 II metodo processBlock() 

Questo è il metodo principale della classe, e di conseguenza anche del plughi inte¬ 
ro. Anch’esso viene generato con l’etichetta override. Come anticipato nell’esempio 
precedente, processBlockO riceve in ingresso dall’host un buffer di campioni di lun¬ 
ghezza fissata (che riempirà coi campioni processati) e il buffer dei messaggi MIDI. 
Prima dell’elaborazione il buffer audio viene ripulito per evitare che vengano ripro¬ 
dotti campioni non appartenenti al blocco in questione [1]. I valori dei livelli vengono 
poi presi dai rispettivi puntatori e salvati in locale [2], 

I canali sono gestiti all’interno del ciclo for, mentre al di fuori di esso viene gestito 
il canale Master. Per ogni canale viene chiamato il metodo renderNextBlockO nel 
synth corrispondente, passandogli il blocco audio da riempire, i messaggi MIDI, il 
campione da cui iniziare a fare il render e il numero di campioni del blocco [3]. Il 
synth esamina i messaggi in arrivo e, nel caso trovi un Note On, riempirà il buffer 
coi campioni presi dal suono corrispondente alla nota e alla velocity del messaggio. Il 
suono verrà fuori blocco dopo blocco finche non si esaurisce del tutto la sua durata. 

II mixaggio dei canali avviene contestualmente a questa chiamata, a ogni iterazione 
del ciclo: un synth avente un suono attivo in un dato momento, riempirà lo stesso 
buffer audio con i propri campioni; il secondo synth quindi sovrascriverà il buffer che 
già il primo aveva riempito e così via. Prima di terminare il ciclo, al blocco viene 
applicato il rispettivo guadagno [4] il quale, nel caso ci sia il muto attivato per quel 
canale, viene impostato a zero [5]. 
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La condizione dell’if [6] si verifica se lo slider del volume non viene spostato, di 
conseguenza viene semplicemente applicato il currentChannelGain al canale. Altri¬ 
menti se si prova a spostare lo slider, verrà creata una rampa di volume tra il livello 
precedente e quello attuale [7]: in questo modo non si percepiranno sbalzi di volume 
durante la performance. 

Finito il ciclo, le stesse operazioni fatte sui livelli dei canali vengono ripetute sul buffer 
ora contenente il loro mix, questa volta coi parametri provenienti dal canale Master. 
11 blocco audio così modificato può essere finalmente passato alla scheda audio per 
poi essere riprodotto. 

// PluginProcessor.cpp 

void DrumProcessor:rprocessBlock (AudioSampleBuffer& buffer, 

MidiBuffer& midiMessages) 

{ 

auto totalNumlnputChannels = getTotalNumlnputChannelsO; 
auto totalNumOutputChannels = getTotalNumOutputChannels(); 
auto busCount = getBusCount (false) ; 

for (auto i = totalNumlnputChannels; i < totalNumOutputChannels; ++i) 

buffer.clear(i, 0, buffer.getNumSamples()); // [1] 

auto currentMasterGain = *masterLevel; // [2] 

//========= Gestione canali ========= 

for (auto busNr = 0; busNr < busCount; ++busNr) { 
if (outputs[busNr] != "Empty") { 

auto currentChannelGain = *level[busNr]; // [2] 

// Process current audio block 
synth[busNr]->renderNextBlock (buffer, 

midiMessages, 

0, 


buffer.getNumSamples()) ; // [3] 

// Mute 

if (isChannelMuteEnabled[busNr]) { currentChannelGain = 0; } // [5] 

// Level 

if (currentChannelGain == previousChannelGain[busNr]) // [6] 

buffer.applyGain(currentChannelGain); // [4] 

else { 

buffer.applyGainRamp II [7] 


( 0 , 

buffer.getNumSamples(), 
previousChannelGain[busNr] , 
currentChannelGain); 

previousChannelGain[busNr] = currentChannelGain; 

> 

> 


> 
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//========= Gestione Master ========= 

// Mute 

if (isMasterMuteEnabled) 

{ currentMasterGain = 0; } 

Il Level 

if (currentMasterGain == previousMasterGain) 
buffer.applyGain(currentMasterGain); 
else 
{ 

buffer.applyGainRamp 

( 0 , 

buffer.getNumSamples(), 
previousMasterGain, 
currentMasterGain); 

previousMasterGain = currentMasterGain; 

> 

> 


3.2.3 I metodi createParameters() e attachParametersQ 

Le istruzioni per la creazione dei parametri sono provvisorie poiché, a partire dalla 
versione 5.4 (rilasciata durante il tirocinio), JUCE ha aggiornato la classe che si oc¬ 
cupa dei parametri (AudioProcessorValueTreeState), costringendo gli sviluppatori 
a rivedere il codice dei propri plughi per far fronte alla modifica. In particolare sono 
stati introdotti diversi tipi di AudioParameter, a seconda che essi siano di tipo f loat, 
int, bool e così via, il che rende più f un zionale e coerente la loro gestione. Inoltre il 
metodo createAndAddParameter () è stato deprecato, e verrà rimosso dal framework 
nelle versioni future. In questo momento, per retrocompatibilità è ancora inglobato 
in esso, ma con alcuni cambiamenti. Il codice presentato in questo elaborato è stato 
sviluppato sulla versione 5.4 e utilizza in questo metodo una sintassi ibrida tra la 
versione precedente e quella aggiornata. In particolare, invece che ricevere una serie 
di attributi come argomenti come in passato, ora il metodo accetta un solo smart 
pointer il quale a sua volta viene inizializzato con gli attributi come argomenti. Lo 
smart pointer (letteralmente puntatore intelligente ) è un potente strumento messo a 
disposizione da C++ che ha la caratteristica di eliminare sé stesso automaticamente 
alla fine del proprio scope, per cui consente una gestione più sicura della memoria 
impedendo i cosiddetti memory leak. 

Per non creare confusione e ingombro nel codice, le creazione e il collegamento dei 
parametri sono stati da me raggruppati nei due metodi custom createParameters () 
e attachParameters(), ognuno dei quali viene chiamato nel costruttore come visto 
prima. 
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Al metodo createParameters () vengono passati due argomenti, il ValueTreeState 
sul quale creare i parametri, e l’indice del canale per il quale questi verranno creati. 
La creazione di un parametro, come si può intuire, avviene attraverso 
createAndAddParameter (), al quale vanno passati gli argomenti che descrivono le 
caratteristiche del parametro stesso. Le chiamate al metodo (una per ogni parametro) 
per quanto riguarda il Master sono poste all’interno di un if [1] che controlla il valore 
di isMasterSet, impostato a false al momento della sua inizializzazione. Dopo la 
creazione, isMasterSet è impostato a true [2] in modo che i parametri del Master 
vengano creati solo una volta: alla successiva chiamata di createParameters () la 
condizione if (! isMasterSet) varrà quindi false impedendo l’esecuzione del codi¬ 
ce al suo interno, altrimenti verrebbe generato un errore dal debugger. I parametri 
fin’ora implementati per il master sono LeveI, Pan e Mute. In seguito all’istruzione 
if sono presenti le chiamate per la creazione dei parametri di un canale, che sono in 
numero più elevato rispetto al Master. In particolare essi sono: 

• Gestione dei livelli 

— Level (range da 0 a 1) 

— Pan (range da -1 a 1) 

— Mute 

— Solo 

• Gestione del pitch 

— Coarse tuning (range da -36 a 36, espresso in semitoni) 

— Fine tuning (range da -100 a 100, espresso in centesimi di semitono) 

In queste chiamate, per i parametri che lo richiedono, vanno definite due funzioni 
da passare come ultimi argomenti: la funzione posta nel campo valueToText de¬ 
finisce come dev’essere rappresentato in forma di stringa il valore float usato dal 
processore, ai fini della sua corretta visualizzazione sull’interfaccia grafica, mentre 
quella nel campo textToValue svolge il ruolo opposto. A causa dell’aggiornamento 
di JUCE, questi metodi sono tutt’ora in fase di adattamento e per questo moti¬ 
vo al posto di essi è stato inserito nullptr. Le operazioni su curOut e paramlD 
prima di ogni creazione [3] servono per costruire dinamicamente le stringhe con¬ 
tenenti rispettivamente il nome e l’ID di ogni parametro appartenente ai canali. 
Per questioni di spazio, viene incluso come esempio solo il codice relativo alla creazione 
di alcuni parametri, gli altri sono da intendersi creati in maniera simile: 
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Il PluginProcessor.cpp 

void DrumProcessor: :createParameters(AudioProcessorValueTreeState& parameters, 

int i) 

{ 

// Master =============================== 

if (!isMasterSet) // [1] 

{ 


// Level 

parameters.createAndAddParameter ( 

std::make_unique<AudioParameterFloat> 

("pMasterLevel" , // ID parametro 

"Master Level", // Nome Parametro 

O.Of, l.Of, l.Of) // Valore minimo, massimo e default 


); 

// Pan 

parameters.createAndAddParameter ( 

// Come sopra, con range da -1 a 1 e default a 0 

); 

// Mute 

parameters.createAndAddParameter ( 

std::make_unique<AudioParameterBool> 
("pMasterMute" // ID parametro 
"Master Mute", // Nome parametro 

false, // Valore default 

// Suffisso 

nullptr, // valueToText 

nullptr) // textToValue 

); 

isMasterSet = true; // [2] 


} 

// Canali ====================== 

String curOut = outputs[i]; 
paramID.clear(); 

paramID << "p" << curOut; // [3] 


// Mixer ==== 


// Level, Pan, Mute come sopra... 

curOut = outputs[i]; 

paramID.clear(); 

paramID << "p" << curOut; 

// Solo 

parameters.createAndAddParameter ( 

std: :make_unique<AudioParameterBool> 
(paramID << "Solo", 
curOut << " Solo", 
false , 


Il II 

5 

nullptr, nullptr)); 
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curOut = outputs[i]; 
paramID.clear(); 
paramID << "p" << curOut; 

// Tuning ==== 

// Coarse 

parameters.createAndAddParameter ( 

std: :make_unique<AudioParameterFloat> 

(paramID « "Coarse", 
curOut « " Coarse", 

NormalisableRange<f loat> (-36.Of, 36.Of, l.Of), 
O.Of, 

StringC'st") , 

AudioProcessorParameter: :genericParameter, 
nullptr, nullptr) 

); 

curOut = outputs[i]; 
paramID.clear(); 
paramID << "p" << curOut; 

// Fine 

parameters.createAndAddParameter ( 

// Come sopra, con range da +100 a - 100, default 0 

); 

paramID.clear(); 


I parametri così creati vengono collegati ai rispettivi puntatori attraverso il metodo 
attachParameters (). Si ricorda che il seguente codice viene chiamato ripetutamente 
per ogni canale attivo (o meglio per ogni canale il cui nome è diverso da ‘Empty’, in 
questo caso i primi due). 

Questa volta, a differenza della creazione, non è necessario che i parametri del Master 
vengano collegati solo la prima volta, poiché a ogni chiamata vengono semplicemente 
sovrascritti con lo stesso valore precedente, senza che ciò provochi errori nell’esecuzio- 
ne. Da notare che, per quanto riguarda i canali, i parametri Level, Mute e Solo sono 
collegati a puntatori sul processore, mentre le funzioni di Pan e Tuning devono agire 
su ogni voce creata. Per questo motivo i parametri che le controllano sono collegati 
ad ogni voce all’interno di un ciclo [4]. Anche qui vale lo stesso discorso fatto per il 
Master, cioè che i puntatori sul processore vengono sovrascritti col medesimo valore 
ad ogni iterazione del ciclo, senza provocare errori: 
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Il PluginProcessor.cpp 

void DrumProcessor: :attachParameters (int midiChannel) 

{ 

paramID.clearO ; 
paramID = "p" ; 

// Master 

masterLevel = parameters. getRawParameterValue("pMasterLevel") ; 
masterPan = parameters.getRawParameterValue ("pMasterPan") ; 

// Canali 

auto channelName = outputs[midiChannel]; 

auto numVoices = synth[midiChannel]->getNumVoices(); 

if (numVoices != 0) 

{ 

for (auto i = 0; i < numVoices; i++) // [4] 

{ 

auto currentVoice = static_cast<DrumVoice*> 

(synth[midiChannel]->getVoice(i)); 
auto sampleRate = currentVoice->getSampleRate(); 

level[midiChannel] = parameters.getRawParameterValue 

(paramID << channelName << "Level"); 

paramID. clearO ; 
paramID << "p"; 

isChannelMuteEnabled[midiChannel] = parameters.getRawParameterValue 

(paramID << channelName << "Mute"); 

paramID. clearO ; 
paramID << "p"; 

isChannelSoloEnabled[midiChannel] = parameters.getRawParameterValue 

(paramID << channelName << "Solo"); 

paramID. clearO ; 
paramID << "p"; 

currentVoice->pan = parameters.getRawParameterValue 

(paramID << channelName << "Pan"); 

paramID. clearO ; 
paramID << "p"; 

currentVoice->coarse = parameters.getRawParameterValue 

(paramID << channelName << "Coarse"); 

paramID. clearO ; 
paramID << "p"; 

currentVoice->fine = parameters.getRawParameterValue 

(paramID << channelName << "Fine"); 

paramID. clearO ; 

> 

} 

> 
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3.2.4 I metodi getStatelnformationQ e setStatelnformationQ 

Il framework mette a disposizione questi due metodi per il salvataggio e caricamento 
delle informazioni sull’intero stato del plughi in/da un blocco di memoria (anche qui è 
obbligatorio eseguire l’override). AudioProcessorValueTreeState salva i suoi stati 
su un file XML dal quale trae le informazioni sui suoi stati precedenti, consentendo 
hannullamento delle modifiche ai parametri. Il codice qui di seguito è stato preso 
dal relativo tutorial sul sito ufficiale di JUCE: durante l’esecuzione, quando il plughi 
vuole caricare il proprio stato, viene chiamato getStatelnf ormationO, nel quale si 
esegue prima la copia in locale dello stato del ValueTreeState [1], poi la creazione 
del file XML contenente lo stato, che viene passato ad uno smart pointer [2]. Infine 
avviene la copia delle informazioni da esso: il blocco di memoria destData passato 
come argomento viene riempito coi dati convertiti in binario per poter essere usati 
dal plughi [3]. 


// PluginProcessor.cpp 



void DrumProcessor::getStatelnformation (MemoryBlock& destData) 
s 


auto state = parameters.copyState(); 

// 

[1] 

std::unique_ptr<XmlElement> vts_xml(state.createXml()); 

// 

[2] 

copyXmlToBinary(*vts_xml, destData); 

} 

// 

[3] 


Quando invece il plughi vuole salvare il suo stato, esso chiama il metodo 
setStatelnformationO dove viene svolto il lavoro opposto, ovvero i dati in bi¬ 
nario vengono letti e convertiti in formato XML, per poi essere passati ad uno smart 
pointer [4]. Lo stato del plughi viene prima controllato [5], quindi rimpiazzato con 
quello attuale [6]. 

// PluginProcessor.cpp 

void DrumProcessor::setStatelnformation (const void* data, int sizelnBytes) 

{ 

std::unique_ptr<XmlElement> 

xmlState(getXmlFromBinary(data, sizelnBytes)); // [4] 

if (xmlState.get() != nullptr) 

if (xmlState->h.asTagName(parameters.state.getType())) // [5] 

parameters.replaceState(ValueTree: :fromXml(*xmlState)); // [6] 

> 
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3.3 La classe DrumSynth 

In questa classe viene definito il synth: qui avviene la creazione dei suoni e delle voci, 
la gestione dell’input MIDI e del MIDI Learn. La classe è derivata da Synthesiser, 
così come le sottoclassi DrumSound e DruraVoice sono derivate rispettivamente da 
SynthesiserSound e SynthesiserVoice. 

Innanzitutto viene definita un enumerazione contenente i valori di terminazione 
per i vari cicli [1], che verranno presto analizzati. Quando viene creato nel processore, 
al synth viene passato come argomento il nome del canale che esso rappresenta. Que¬ 
sta stringa, copiata in locale [2], viene usata per costruire i nomi dei file corretti da 
caricare e per altri controlli analoghi a quelli visti in DrumProcessor (escludendo i ca¬ 
nali aventi nome ‘Empty’). A questo punto, in base al numero salvato in maxVoices, 
vengono aggiunte le diverse istanze di DrumVoice al synth [3]; in seguito la chiamata 
a addSoundsO crea i suoni che saranno riprodotti dalle voci [4], 


// DrumSynth.h 

class DrumSynth : public Synthesiser 
{ 

public : 

enum // [1] 

{ 

maxSoundsPerRange = 1, 
maxVoices = 10, 
numVelocityRange = 8 

>; 


DrumSynth(String name) 
{ 


chName = name; 

// 

[2] 

for (int i = maxVoices; —i >= 0;) 
addVoice(new DrumVoice()); 

// 

[3] 

addSounds(); 

// 

[4] 


} 

II 
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3.3.1 II metodo addSounds() 

La creazione degli oggetti DrumSound avviene in questo metodo sviluppato dal sot¬ 
toscritto per agevolare le operazioni e ingombrare meno spazio nel costruttore di 
DrumSynth. La quantità dei suoni da aggiungere per ogni synth è determinata dai 
valori stabiliti nell’enum vista prima. In particolare, si avrà un numero di suoni ugnale 
a maxSoundPerRange moltiplicato per numVelocityRange. La scala di valori di velo- 
city viene divisa in un numero di range definito in numVelocityRange: ad esempio 
se avessimo questo valore uguale a 2, sarà generato un range che va da 1 a 64 e un 
altro da 64 a 128. Lo zero non viene contato poiché implica un Note Off, mentre il 
128 viene incluso nel range nonostante il suo valore non sia contemplato dall’inter¬ 
faccia MIDI. Questo perchè i range generati hanno l’inizio inclusivo ma non la fine, 
in modo che quest'ultima diventi a sua volta l’inizio del range successivo. Se quindi 
l’ultimo range generato avesse fine impostata a 127, un Note On a velocity massima 
non innescherebbe alcun suono, perchè questo valore sarebbe escluso dal range. 

In realtà il framework utilizza valori di velocity in floating point normalizzati da 
0 a 1, per cui nell’esempio precedente i valori effettivi generati sarebbero da 0.007 
a 0.507 circa per il primo range e da 0.507 a 1.007 circa per il secondo. Nel caso 
del plugin il totale verrà spezzettato in 8 range con un singolo suono per ognuno. 
Il numero dei file caricati quindi (con due synth all’attivo) sarà 16. 

Il codice qui di seguito è abbastanza autoesplicativo: prima di tutto viene dichia¬ 
rato l’oggetto Range e il valore massimo di velocity [1]. Poi vengono definiti i valori 
start e lenght di partenza [2], che subito dopo sono usati per stabilire i limiti dei 
vari range all’inizio del ciclo più esterno. Nel for interno invece, quindi all’interno 
del range appena definito, viene chiamato il metodo addSoundO - già incluso nella 
libreria JUCE - al quale viene passato un nuovo puntatore a DrumSound. Prima della 
creazione effettiva, questo viene salvato localmente in un puntatore chiamato sound, 
in modo da non perderne il riferimento [3]. Dopo la creazione, proprio attraverso 
questo puntatore, vengono quindi passati al suono il nome del canale (”Kick”, ”Sna- 
re”...), il range di velocity e la nota MIDI coi quali esso si dovrà innescare, infine il sno 
indice all’interno dello stesso range (da 1 a maxSoundsPerRange) [4], Dopo questo 
ciclo start viene incrementato in modo da coincidere con la fine del range attuale 
[5]: nel caso start sia maggiore o uguale a velocityTot si esce dal ciclo poiché è 
stato raggiunto il limite [6], e non ci sono quindi altri range da generare. Altrimenti 
si continua con le iterazioni successive finché non viene soddisfatta la suddetta con¬ 
dizione. 
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// DrumSynth.h 

void addSoundsO 

{ 

Range<float> velocityRange; 

float velocityTot = l.Of; // [1] 

float start = l.Of / 128.Of; 

float const lenght = velocityTot / numVelocityRange; // [2] 

for (float range = 1; range <= numVelocityRange; range++) 

{ 

velocityRange.setStart(start); 

velocityRange.setEnd(start + lenght); 

for (index = 1; index <= maxSoundsPerRange; index++) { 
addSound(sound = new DrumSound()); 
sound->setName(chName); 
sound->setVelocityRange(velocityRange); 
sound->setMidiNote(note); 
sound->setIndex(index); 

> 

start += lenght; 

if (start > velocityTot) 
break; 

> 

} 


// [3] 

// [4] 

// [5] 
// [ 6 ] 


3.3.2 II metodo handleMidiEventQ 

Il presente metodo è messo a disposizione dal framework come virtuale puro, quindi 
come per gli altri di questo tipo il suo scheletro è stato generato automaticamente 
con l’etichetta override, lasciando al sottoscritto il resto del codice. Qui avviene, 
come si evince dal nome, la gestione degli eventi MIDI in arrivo. Se l’evento at¬ 
tuale è un messaggio di Note On [1], allora viene controllato lo stato del boolcano 
isMidiLearning [2], Quando si preme un pulsante Learn nella GUI, il booleano è 
impostato a true e il synth si pone in attesa di input. Al primo Note On ricevuto, il 
messaggio viene usato per invocare il metodo midiLearnO invece che innescare un 
suono. In generale invece il comportamento del synth sarà semplicemente quello di 
invocare il metodo noteOnO [4] se il messaggio in ingresso è appunto un Note On. 
Prima di uscire dall’if, viene chiamato il metodo voicesToLogO che stampa sul log 
la voce incaricata alla riproduzione per finalità di testing [5]. Esso verrà analizzato 
in dettaglio nel capitolo 4. 
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Allo stato attuale il synth reagisce solo a messaggi di tipo Note On. Tutti gli altri tipi 
di messaggio hanno delle istruzioni if analoghe, all’interno delle quali non è presente 
però nessun codice [6]. 


// DrumSynth.h 



void handleMidiEvent (const MidiMessage& m) override 
{ 

const int channel = m.getChannelO; 



if (m. isNoteOnO ) 
s 

// 

[1] 

\ 

if (isMidiLearning) 

// 

[2] 

midiLearn(m); 

// 

[3] 

else 

{ 

noteOn(channel, m.getNoteNumberO , m.getFloatVelocityO) ; 

// 

[4] 

voicesToLog(m.getNoteNumber(), m.getFloatVelocityO); 

} 

// 

[5] 

> 

else if (m.isNoteOff()) {} 

// 

[6] 

// ... 



> 




3.3.3 II metodo noteOn() 

Il codice riportato qui sotto innesca la voce che riprodurrà il suono corrispondente. 
Questo metodo è già implementato nella classe base e normalmente basta utilizzare 
il codice di JUCE per essere in grado di riprodurre dei suoni. In questo caso invece 
è stato eseguito l’override sul metodo modificando leggermente il codice già pronto, 
per andare incontro alle esigenze di gestione velocity e MIDI Learn. Come si può in¬ 
tuire dalla chiamata all’interno di handleMidiEvent(), il metodo noteOnO accetta 
in ingresso 3 argomenti, ovvero il canale MIDI nel quale si trova il messaggio di Note 
On, il numero della nota suonata e la sua velocity. 

Come prima cosa viene creata una sezione critica per assicurare che l’accesso al codice 
venga eseguito da un solo flusso di esecuzione [1]. A questo punto, contestualmente 
al primo ciclo f or, viene creato un puntatore a SynthesiserSound, usato per iterare 
all’interno dcll’array sounds [2]: questo vettore è interno al framework e viene creato 
automaticamente durante le chiamate di addSoundO e contiene tutti i suoni creati. 
Essendo un array interno, è necessario che il puntatore qui usato sia del tipo della 
classe base, mentre per eseguire le operazioni richieste dal progetto il tipo dev’essere 
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quello della classe derivata: infatti la prima operazione di ogni iterazione del ciclo è 
una conversione (cast) del puntatore a DrumSound [3], in modo da poter utilizzare il 
metodo custorn appliesToO. Questo metodo così come appliesToChannel () - che 
invece è di default - restituisce un valore booleano a seconda che il suono in consi¬ 
derazione rientri nei parametri passati come argomento. Se quindi il suono attuale è 
stato configurato per essere innescato con l’attuale nota MIDI, velocity e canale, allo¬ 
ra verrà invocato startVoiceO che riprodurrà il suono, altrimenti si passa al suono 
successivo nell’array e così via. noteOnO, nella sua versione predehnita, controlla il 
valore di appliesToNoteO e appliesToChannel() prima di chiamare startVoiceO: 
normalmente quindi la velocity verrebbe semplicemente passata come argomento a 
quest’ultimo metodo, dal quale verrebbe poi internamente moltiplicata per il livel¬ 
lo di intensità del suono. Questo è un comportamento indesiderato per il plugin in 
questione. appliesToNoteO è stato quindi sostituito in questa istruzione if [4] con 
appliesToO, che restituisce true se la nota suonata corrisponde a quella assegnata 
al suono in questione, e se la velocity passata come argomento rientra nel range dato al 
suono durante la sua creazione. Da notare che in addSounds (), alla prima esecuzione, 
viene impostata una nota di riferimento attraverso la chiamata setMidiNote(note), 
ma quando ciò accade la variabile note non è ancora stata inizi a, li zzata. In sintesi 
finche il synth non viene mappato su una nota fissa attraverso il metodo midiLearnO, 
esso non sarà abilitato a suonare alcun campione in quanto appliesToO restituirà 
sempre false. Questo comportamento è pressoché conforme ad altri plugin di batterie 
acustiche sul mercato, nel senso che questi solitamente implementano una mappatu¬ 
ra standard predefinita, di conseguenza - a differenza del presente progetto - sono 
abilitati a suonare già in partenza. Tuttavia, in condizioni realistiche, raramente un 
dispositivo MIDI - come una batteria elettronica - si interfaccia agevolmente con le 
mappature standard, rendendo comunque necessaria la rimappatura del plugin attra¬ 
verso MIDI Learn. Questo argomento verrà approfondito maggiormente nel prossimo 
paragrafo. 

Se le condizioni sono soddisatte dunque, vengono svolte le operazioni di default 
per riprodurre il suono [5]: startVoiceO accetta 5 argomenti, il primo dei quali 
dev’essere un puntatore alla voce, il secondo un puntatore al suono mentre gli altri 
si ritengono essere autoesplicativi. Il puntatore a SynthesiserVoice richiesto come 
primo argomento viene fatto restituire dal metodo findFreeVoice(), il quale (co¬ 
me da comportamento predefinito) trova una voce libera - cioè non impegnata nel 
rendering di un altro suono - e la usa come valore di return. Questa sarà quindi la 
voce che riprodurrà il suono corrente. In conclusione quindi le uniche modifiche al 
codice già pronto sono state il cast a DrumSound invece che a SynthesiserSound, e 
la chiamata ad appliesToO invece che ad appliesToNoteO. 
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// DrumSynth.h 

void noteOn (const int midiChannel, 

const int midiNoteNumber, 
const float velocity) override 

{ 

const ScopedLock sl(lock); // [1] 

for (auto* soundSource : sounds) // [2] 

{ 

auto* const sound = static_cast<DrumSound* const> (soundSource); // [3] 

if (sound->appliesTo(midiNoteNumber, velocity) 

&& sound->appliesToChannel(midiChannel)) // [4] 

{ 

startVoice ( // [5] 

findFreeVoice(sound, midiChannel, midiNoteNumber, shouldStealNotes), 
sound, 

midiChannel, 
midiNoteNumber, 
velocity); 

> 

} 

> 


3.3.4 II metodo midiLearn() 

Questo metodo implementa la funzione di MIDI Learn, anche chiamata Team from 
MIDI\ che consente di assegnare ad ogni synth una nota di riferimento. Il synth 
produrrà suoni solo alla ricezione di quella nota, mentre per tutte le altre non farà 
nulla. Questa funzione non è presente in libreria ed è stata sviluppata ad hoc per 
gli scopi del progetto. Come brevemente anticipato, il metodo è molto utile per in¬ 
terfacciare velocemente il proprio dispositivo MIDI con il plugin: basterà attivarla 
con l’apposito pulsante sulla GUI e suonare la nota che si vuole usare per riprodurre 
i suoni del canale, e così via per tutti i canali che si desidera mappare. Ciò risulta 
indubbiamente utile nel caso si suoni il plugin ad esempio con una tastiera MIDI, 
ma diventa fondamentale nelhutilizzo di una batteria elettronica, poiché ogni pad ha 
posizioni fìsse che si rifanno quasi sempre agli stessi pezzi della batteria (ad esem¬ 
pio la grancassa sarà quasi sempre suonata dal pad al quale è collegato il pedale, e 
così via). Spesso inoltre ogni pad suona una nota MIDI il cui numero dipende dal 
modulo sonoro della batteria stessa: i pad in sé infatti non inviano MIDI, ma solo 
informazioni in forma analogica riguardanti l’intensità della loro vibrazione; queste 
vengono interpretate dal modulo come velocity e da esso vengono inviate in forma di 
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messaggio alla porta MIDI di uscita. Le note associate ad ogni pad sono quindi a 
discrezione del modulo, e spesso e volentieri non sono contigue tra loro, ma anzi sono 
sparse tra le 128 disponibili, rendendo la mappatura potenzialmente molto frustrante 
se si vuole assegnare manualmente un suono ad una nota. 

Tutto ciò viene fortunanamente evitato grazie a questa utile funzione, realizzata 
in gran parte in questo metodo custom. Si ricorda che esso viene chiamato alLinterno 
di handleMidiEvent () nel caso il valore di isMidiLearning sia true. Premere uno 
dei bottoni Team 1 sulla GUI ha l’effetto di impostare questo valore appunto a true, 
ovviamente per il synth corrispondente. L’implementazione è molto semplice: prima 
di tutto la nota ricevuta come argomento viene copiata in locale [1] ; in seguito si itera 
nclharray dei suoni analogamente a quanto visto in noteOnO, e per ogni suono del 
synth la nota viene impostata come nota di riferimento [2], Infine isMidiLearning 
viene reimpostato a false [3] cosicché il plugin possa riprendere a riprodurre i suoni 
come da predehnito. Ora ad ogni chiamata di noteOnO il controllo su appliesToO 
potrà restituire true, innescando di conseguenza il suono. 

// DrumSynth.h 

void midiLearn(const MidiMessage& msg) 

{ 

note = msg.getNoteNumberO ; // [1] 

for (auto* soundSource : sounds) 

{ 

auto* const sound = static_cast<DrumSound* const> (soundSource); 
sound->setMidiNote(note); // [2] 

> 

isMidiLearning = false; // [3] 

1 


3.4 La classe DrumSound 

Questa è la classe deputata principalmente al caricamento dei file in memoria. Per 
gli scopi di questo progetto, è stato ritenuto secondario gestire la lettura dei file di¬ 
rettamente dal disco, a causa dei problemi di latenza causati da questo approccio. 
La tattica adottata quindi è quella di creare una copia dei suoni e salvarla in RAM, 
in modo da poter leggere velocemente il corretto campione in seguito alla ricezione 
di un Note On, per poi riprodurlo; tutto ciò viene fatto senza il bisogno di troppe 
ottimizzazioni e in tempi trascurabili dalla percezione umana, a differenza dell’ap¬ 
proccio da disco fisso, con il quale per raggiungere un tale obbiettivo bisognerebbe 
avere un codice molto efficiente, la cui stesura è stata quindi lasciata a sviluppi futuri. 
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Il salvataggio in memoria centrale ha però un risvolto negativo: vista la comples¬ 
sità dei kit di batteria e la gran quantità di suoni per ognuno, per eseguire il plughi 
senza problemi servirebbe una RAM molto grande - nell’ordine dei 16/32 GB o oltre - 
il che è quasi impensabile o comunque non permetterebbe a molti l’utilizzo del plughi. 
Attualmente i suoni che vengono caricati sono relativamente pochi in modo da age¬ 
volare testing e ulteriori sviluppi. 

La classe è stata implementata in modo che ogni suono venga caricato da un 
thread dedicato, per gestire al meglio le risorse: essa eredita quindi, oltre che da 
SynthesiserSound, anche da Thread. Nel costruttore di DrumSound abbiamo prima 
l’inizializzazione del thread [1], poi la chiamata del f ormatManager serve a permet¬ 
tere la lettura dei formati affé wav [2], Infine la chiamata a startThreadO [3] 
causa internamente l’invocazione del metodo run(), all’interno del quale è stato im¬ 
plementato il codice che svolge il caricamento. Nel distruttore invece il thread viene 
terminato regolarmente [4]: se ciò non viene fatto entro 4 secondi, ad esempio perchè 
il thread è bloccato, esso sarà terminato forzatamente (questo però, di regola, non 
dovrebbe accadere mai). 

// DrumSound.h 

class DrumSound : public SynthesiserSound, 
private Thread 

{ 

public : 

DrumSoundO : Thread ("DrumSound Thread") // [1] 

{ 

formatManager.registerBasicFormats(); // [2] 

start ThreadO ; // [3] 

> 


"DrumSound() 

{ 

stopThread(4000); 

} 


// [4] 


Il metodo run() viene fornito dalla classe Thread per consentire l’esecuzione del¬ 
le operazioni che il thread stesso deve svolgere. Esso ha un’implcmentazione molto 
semplice: al suo interno troviamo un ciclo while che controlla il valore restituito 
dal metodo threadShouldExit(), che inizialmente sarà false. Di regola il codice 
che si vuole far eseguire al thread va posto all’interno di questo ciclo [5], in modo 
che le operazioni al suo interno siano garantite come threadsafe. La chiamata di 
stopThreadO nel distruttore invece, fa in modo che threadShouldExit() restitui¬ 
sca true e di conseguenza il thread terminerà di eseguire le operazioni all’interno 
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del ciclo. Fintanto che ciò non accade, il thread imposta il percorso del file da apri¬ 
re con la chiamata a setPathO [6] e ne carica il contenuto in memoria attraverso 
readFromPathO [7]. Questi due metodi, sviluppati dal sottoscritto, verranno visti in 
dettaglio più avanti. Per impedire che essi vengano richiamati continuamente, e che 
quindi il file venga caricato innumerevoli volte in memoria, viene usato il booleano 
isPathSet come condizione dell’istruzione if [8] in maniera analoga a quanto visto 
nella creazione dei parametri. 

// DrumSound.h 

// ... 

private : 
void runQ 
{ 

while (!threadShouldExit()) // [5] 

{ 

if (!isPathSet) { 

setPathO; // [6] 

readFromPath(path); // [7] 

> 

wait(500); 

> 

> 

// ... 


Tutti i metodi, gli oggetti e le variabili appartenenti al thread o comunque alla gestione 
del caricamento, sono dichiarate sotto l’etichetta private, in modo che nessun’altra 
classe possa utilizzarli. Sono poi stati creati altri metodi custom di utilità generale, 
oltre a due già presenti di default, tutti dichiarati sotto public poiché necessitano di 
essere chiamati esternamente alla classe. Le chiamate a questi metodi infatti sono già 
state viste nei metodi addSoundsO e midiLearnO all’interno della classe DrumSynth. 
Essi sono stati raggruppati insieme nel codice qui di seguito, poiché necessitano di 
poco ingombro e sono di semplice comprensione: 
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// DrurnSound.h 

H ... 

// Metodi custom 

void setName(String name) { chName = name; }; // nome canale 

void setlndex(int i) { index = i; } // indice 

void setMidiNote(int noteToSet) // nota di riferimento 

{ 

playingMidiNote = noteToSet; 
return; 

> 

void setVelocityRange(Range<float> range) // range di riferimento 

{ 

auto start = range.getStart(); 
auto end = range .getEndO ; 
velocity.setStart(start); 
velocity.setEnd(end); 

> 

bool appliesTo (int midiNoteNumber, float vel) 

{ 

bool appliesToMidiNote = appliesToNote(midiNoteNumber); // [10] 
bool isInVelocityRange = this->velocity.contains(vel); // [11] 

return appliesToMidiNote && isInVelocityRange; // [9] 

} 

// Metodi default 

bool appliesToNote (int midiNoteNumber) override 

{ 

if (midiNoteNumber == playingMidiNote) 
return true ; 
else 

return false; 

> 

bool appliesToChanneldnt midiChannel) override { return true; } 

// ... 


Come si può intuire i vari metodi che iniziano con la parola ’set’ servono semplicemente 
a salvare nelle variabili private i valori passati dalle altre classi durante le chiamate. 
Il metodo appliesTo() invece è stato creato per consentire il controllo sul range di 
velocity, oltre che sulla nota MIDI di riferimento. Esso restituisce true nel caso in 
cui sia la nota ricevuta corrisponda alla variabile impostata da setMidiNoteO, sia 




CAPITOLO 3. IL PLUGIN DRUM SAMPLER 


36 


la velocity in ingresso ricada nel range di riferimento per il suono [9]. Per il controllo 
della nota viene utilizzato il valore di ritorno del metodo default appliesToNoteO 
[10], mentre per quanto riguarda la velocity, attraverso l’operatore this viene fatto 
l’accesso all’oggetto di tipo Range<f loat> chiamato velocity; se velocity contiene 
il valore vel, isInVelocityRange viene impostato a true [11]. Infine il metodo 
appliesToChannelO è stato lasciato come da default: restituisce sempre true in 
modo che il suono risponda a messaggi provenienti da qualsiasi canale MIDI. 

3.4.1 I metodi setPath() e readFromPath() 

Nel thread dunque vengono chiamati questi due metodi che hanno l’effetto di caricare 
un file in memoria. setPathO non fa altro che costruire la stringa denominata path e 
contenente il percorso da passare a readFromPathO. La soluzione adottata costringe 
il plugin a basarsi sui nomi dei file per il loro corretto caricamento: innanzitutto 
essi devono trovarsi per forza nella cartella denominata ‘Samples’, la quale dev’essere 
all’interno della cartella di lavoro [1]. In più essi devono chiamarsi esattamente come 
descritto nel commento sotto. Ovviamente tutto ciò è poco efficiente, per cui la 
soluzione è da intendersi come provvisoria. Una volta che è stato costruito il percorso 
[2], esso viene stampato sul Logger per motivi di testing [3]. Infine isPathSet viene 
impostato a true impedendo - nel metodo run() - il ricaricamento del file [4], 

// DrumSound.h 
void setPathO 
{ 

String msg; 

auto parentDir = workingDirectory.getCurrentWorkingDirectoryO; 
auto dir = parentDir.getChildFileO ../Samples") ; // [1] 

// Formato nome file: NomePezzo_articolazione_indice_velocity.estensione 
// NomePezzo: Kick, Snare ... 

// indice : 1, 2 ... 

// velocity: il limite inferiore del range 
// estensione: wav 

path << dir . getFullPathNameO << dir .getSeparatorCharO // [2] 

« chName « 

« index << 

<< roundFloatToInt(velocity.getStart()*127) 

<< ".wav"; 

msg << "\nLoading Sample: \n" << path << "\n"; 

Logger::getCurrentLogger()->writeToLog(msg); // [3] 

isPathSet = true; // [4] 

} 
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La stringa path ora contiene quindi il percorso completo del file da copiare in memo¬ 
ria. Essa viene passata come argomento al metodo readFromPathO quando questo 
viene chiamato all’interno di run(). Anche qui il nome del metodo è abbastanza 
autoesplicativo: legge i dati dal percorso che gli è stato passato. 

Inizialmente si controlla che il percorso non sia una stringa vuota [4], caso in cui 
verrebbe saltato l’intero codice del metodo. In seguito viene creato un oggetto di tipo 
File [5] che viene poi passato al metodo createReaderFor() del formatManager. 
Questo metodo cerca attraverso i formati file registrati e prova a creare un lettore 
adatto per il file in questione: se ci riesce lo restituisce, altrimenti restituirà un pun¬ 
tatore nullo. Il lettore quindi viene usato per inizializzare uno smart pointer di tipo 
AudioFormatReader chiamato reader [6]. Ciò come già spiegato lascia al puntato¬ 
re stesso la responsabilità di auto-eliminarsi alla fine del proprio scope, altrimenti 
sarebbe responsabilità dello sviluppatore liberare la memoria. 

Subito dopo, se diverso dal puntatore nullo [7], lo smart pointer viene usato per 
accedere alla frequenza di campionamento e la lunghezza (espressa in campioni) del 
suono, controllando allo stesso tempo se esse siano maggiori di zero [8]. In caso 
positivo la lunghezza viene salvata in locale [9], poi viene creato un nuovo oggetto 
AudioSampleBuffer (un buffer vuoto con numero di canali e lunghezza dipendente 
dal file) che viene salvato in un altro smart pointer denominato data [10]. A questo 
punto si è pronti per usare il metodo read() per trasferire i campioni da reader al 
nuovo buffer [11], Il suono ora è pronto per essere letto e riprodotto. 

// DrumSound.h 

void readFromPath(String pathToOpen) 

{ 


if (pathToOpen. isNotEmptyO ) { 

// 

[4] 

File file(pathToOpen); 

// 

[5] 

reader.reset(formatManager.createReaderFor(file)); 

// 

[6] 

if (reader.get() != nullptr) { 

// 

[7] 

if (reader->sampleRate > 0 && reader->lengthInSamples > 0) 

{ // 

[8] 

lenght = (int)reader->lengthInSamples; 

// 

[9] 

data.reset (new AudioBuffer<f loat> 



(jmin(2, (int)reader->numChannels), 



lenght + 4)); 

// 

[10] 

reader->read (data.getO, 

// 

[11] 


0 , 

lenght, 
0 , 

true , 
true) ; 

> 

> 

> 

} 
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3.5 La classe DrumVoice 

Questa classe gestisce il rendering dei suoni in base ai parametri collegati al pro¬ 
cessore. Qui avviene la lettura del contenuto al quale punta data, contenuto che 
verrà poi modificato a seconda che l’utente abbia modificato o no qualche parametro 
nella GUI. In caso contrario il suono verrà riprodotto senza alterazioni. La classe 
è derivata da SynthesiserVoice ed è stata dichiarata all’interno di DrumSound co¬ 
me friend class: questo permette alla DrumVoice di utilizzare i metodi public di 
DrumSound. Nel costruttore non c’è alcuna necessità di eseguire inizializzazioni, così 
come nel distruttore non bisogna eliminare nulla, mentre nel resto della classe tro¬ 
viamo un semplice metodo (già incluso in libreria) denominato canPlaySoundO, che 
effettua un cast da SynthesiserSound alla classe derivata utilizzata nel plughi, in 
questo caso ovviamente a DrumSound. Nel caso in cui riesca nell’operazione restituisce 
true, altrimenti la funzione dynamic_cast genererà un puntatore nullo e il valore di 
ritorno sarà false. I restanti metodi verranno analizzati nei prossimi paragrafi. 

// DrumSound.h 

class DrumVoice : public SynthesiserVoice 

{ 

public : 

DrumVoice(){} 

"DrumVoice() {} 

bool canPlaySound(SynthesiserSound* sound) override 

{ 

return dynamic_cast<DrumSound*> (sound) != nullptr; 

> 

H ... 


3.5.1 II metodo startNote() 

Anche qui il nome lascia intuire il ruolo di questo metodo: esso viene infatti chiamato 
quando si vuole iniziare la riproduzione di una nota. Il metodo è chiamato interna¬ 
mente da startVoice (), il quale - si ricorda - viene invocato all’interno di noteOnO. 
Essendo un metodo virtuale puro, bisogna effettuare l’override anche in questo caso. 

Per prima cosa se il suono non è del tipo corretto verrà generato un errore dal 
debugger [1], Se invece è corretto, i valori dei parametri sono copiati nelle rispettive 
variabili [2] che rappresentano il numero di semitoni e centesimi di semitono da cui 
dipenderà l’altezza del suono generato. Il resto del codice è stato preso dalla classe 
SamplerVoice, una sottoclasse di SynthesiserVoice che serve per implementare 
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(assieme a SaraplerSound) un campionatore digitale. Queste classi non sono state 
usate per incompatibilità varie e per questioni di semplicità. La loro gestione del 
rendering però si è rivelata funzionante, quindi si è scelto di adottarla in questa classe 
custom, con qualche leggera modifica: in questo metodo semitones e cents sono stati 
aggiunti nel calcolo del pitchRatio [3], a lgain ed rgain invece viene attribuito il 
valore di velocity più alto, anziché quello fornito in ingresso [4], Questo consente che 
il volume dei campioni non venga alterato, coerentemente con le specifiche del plugin. 
Segue poi una serie di controlli (scritti dagli autori del framework) che inizializzano 
un semplice inviluppo il quale verrà utilizzato nel prossimo metodo analizzato. 

// DrumSound. h 

void startNote (int midiNoteNumber, float velocity, SynthesiserSound* s, int 
/*pitchWheel*/) override 

{ 

if (auto* sound = dynamic_cast<const DrumSound*> (s)) 

{ 

semitones = *coarse; 

cents = *fine; // [2] 

attackSamples = roundToInt(attackTime * sound->reader->sampleRate); 
releaseSamples = roundToInt(releaseTime * sound->reader->sampleRate); 
pitchRatio = std::pow(2.0, (semitones + cents * 0.01) / 12.0) * // [3] 

sound->reader->sampleRate / getSampleRate(); 
sourceSamplePosition = 0.0; 
lgain = l.Of /* velocity */; 

rgain = l.Of /* velocity*/; // [4] 

isInAttack = (attackSamples > 0); 
isInRelease = false; 
if (isInAttack) 

{ 

attackReleaseLevel = O.Of; 

attackDelta = (float) (pitchRatio / attackSamples); 

> 

else 

{ 

attackReleaseLevel = l.Of; 
attackDelta = O.Of; 

> 

if (releaseSamples > 0) 

releaseDelta = (float) (-pitchRatio / releaseSamples); 
else 

releaseDelta = -l.Of; 

> 

else 

jassertfalse; // [1] 

} 
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3.5.2 II metodo renderNextBlock() 

Anche qui ci troviamo davanti ad una funzione virtuale pura sulla quale è stato esegui¬ 
to l’override, e anche qui il codice è stato preso da SamplerVoice e modificato per far 
fronte alle esigenze del plughi. Il presente metodo è l’equivalente di processBlockO, 
implementato però nella classe della voce. Il vero lavoro di costruzione del blocco au¬ 
dio viene effettuato qui. mentre nel processBlockO, come si è visto, basta invocare 
il metodo tramite il synth. In realtà il renderNextBlockO chiamato nel processore 
è un metodo della classe Synthesiser: tramite una serie di chiamate interne si arri¬ 
va all’invocazione del renderNextBlockO oggetto di questo paragrafo, altrimenti si 
dovrebbe accedere alla voce tramite il synth (il che implica la creazione di un pun¬ 
tatore a DrumVoice dentro DrumSynth), trovare le voci attualmente in riproduzione 
e per ognuna invocare il metodo. Questo lavoro invece viene svolto internamente dal 
framework. La differenza tra i due metodi omonimi si nota analizzando gli argomenti 
che accettano: quello nel synth riceve, oltre agli altri argomenti, il buffer dei messaggi 
MIDI. In questo invece non c’è il bisogno, poiché semplicemente renderizza continua- 
mente un buffer audio a seconda del contenuto di data, che legge blocco dopo blocco. 
Se però nessun suono è attualmente in riproduzione, la chiamata a 
getCurrentlyPlayingSoundO [1] restituirà false e verrà generato un blocco di 
silenzio. 

Nel caso opposto viene preso un riferimento al suono [2], creati i puntatori che leg¬ 
geranno i valori da data [3] e quelli che scriveranno i campioni sul buffer passato 
come argomento [4]. Finche non si esaurisce il blocco attuale [5] ogni campione viene 
copiato in una variabile f loat (applicando prima una semplice interpolazione lineare) 
[6]. Nelle due righe successive è stata inserita una piccola modifica per implementare 
la funzione Pan sui canali: le variabili sono moltiplicate, oltre che per i rispettivi 
guadagni, anche per il valore preso dal parametro Pan [7]. La funzione jmin - messa 
a disposizione dalla libreria - restituisce il valore più basso tra i due inseriti come 
argomenti: se il valore al quale punta pan rimane inalterato (cioè zero), la funzione 
restituisce uno lasciando inalterati i guadagni, altrimenti verrà applicata la corret¬ 
ta attenuazione per ognuno dei due canali. Segue poi l’inviluppo - inizializzato in 
startNoteO - che controlla se il suono è in fase di attacco o di rilascio, e prende i 
dovuti provvedimenti. Questo inviluppo non altera il suono modificandone attacco e 
rilascio ma piuttosto ne consente la corretta riproduzione. Le modalità con cui ciò 
viene effettuato esulano dagli scopi di questo elaborato, perciò questa porzione di 
codice è volutamente trattata in maniera sintetica. 

Una volta deciso il valore che il campione attuale dovrà assumere, esso viene 
finalmente scritto su outputBuffer attraverso i puntatori creati a inizio metodo. Nel 
caso si abbia un file stereo ognuno dei due campioni viene semplicemente passato al 
rispettivo canale, altrimenti in un contesto mono i campioni vengono prima sommati 
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e poi la loro ampiezza totale viene dimezzata; in seguito sono passati solo al primo 
canale [8]. Infine sourceSamplePosition, che tiene conto della posizione di lettura 
all’interno del suono, viene incrementato col valore di pitchRatio [9], in modo che 
se il pitch impostato è positivo saranno letti meno campioni (ad esempio se si alza il 
suono di un’ottava, sarà letto un campione ogni due), viceversa se il pitch è negativo ne 
vengono letti di più (i campioni mancanti sono generati dall’interpolazione). Questo 
produce l’effetto di aumentare o diminuire l’altezza del suono. Prima di terminare 
l’iterazione del while, se è stata raggiunta la fine del suono, la nota viene fermata e 
si esce dal ciclo [10], altrimenti sarà renderizzato il blocco seguente. 

// DrumSound.h 

void renderNextBlock(AudioSampleBuffer& outputBuffer, 

int startSample, 

int numSamples) override 

{ 

if (auto* playingSound = static_cast<DrumSound*> 

(getCurrentlyPlayingSoundO.get())) // [1] 

{ 

autofe data = *playingSound->data; // [2] 

const float* const inL = data.getReadPointer(O); 
const float* const inR = 

data.getNumChannelsO > 1 ? data.getReadPointer(l) : nullptr; // [3] 

float* outL = outputBuffer.getWritePointer(0, startSample); 
float* outR = outputBuffer.getNumChannels() > 1 

? outputBuffer.getWritePointer(1, startSample) 

: nullptr; // [4] 

while (—numSamples >= 0) // [5] 

{ 

auto pos = (int) sourceSamplePosition; 

auto alpha = (float) (sourceSamplePosition - pos); 

auto invAlpha = 1.Of - alpha; 

float 1 = (inL [pos] * invAlpha + inL [pos + 1] * alpha); 
float r = (inR != nullptr) ? 

(inR[pos] * invAlpha + inR[pos + 1] * alpha) : 1; // [6] 

1 *= lgain * jmin(1.0f - *pan, l.Of); 

r *= rgain * jmin(1.0f + *pan, l.Of); // [7] 

if (isInAttack) 

{ 

1 *= attackReleaseLevel; 
r *= attackReleaseLevel; 
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attackReleaseLevel += attackDelta; 

if (attackReleaseLevel >= l.Of) 

{ 

attackReleaseLevel = l.Of; 
isInAttack = false; 

> 

> 

else if (isInRelease) 

{ 

1 *= attackReleaseLevel; 
r *= attackReleaseLevel; 

attackReleaseLevel += releaseDelta; 

if (attackReleaseLevel <= O.Of) 

{ 

stopNote(0.Of, false); 
break; 

> 

> 

// Passaggio campione al buffer di uscita 
if (outR != nullptr) 

{ 

*outL++ += 1; 

*outR++ += r; 

> 

else 

{ 

*outL++ += (1 + r) * 0.5f; // [8] 

> 

sourceSamplePosition += pitcbRatio; // [9] 

if (sourceSamplePosition > playingSound->lenght) 

{ 

stopNote(0.Of, false); 

break; // [10] 

> 

> 

> 

} 
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3.6 La classe DrumEditor 

L’ultima classe analizzata è chiamata DrumEditor e gestisce tutti gli aspetti dell’in¬ 
terfaccia grafica. Come già anticipato, in essa sono stati implementati solo i controlli 
di base per i vari canali (che sono 9 in totale): nel Master troviamo gli slider per 
il controllo di Level e Pan (con relative etichette), ed il pulsante Mute; nei restan¬ 
ti 8 canali invece, oltre ai tre già citati, è stato aggiunto il pulsante Solo (la cui 
funzione non è ancora stata implementata nel motore) e Learn per attivare il rela¬ 
tivo MIDI Learn. Questi e i restanti parametri (quelli relativi al tuning) possono 
essere comunque modificati grazie ad AudioPluginHost, che genera in automatico un 
GenericEditor (una GUI molto basilare) con uno slider per ogni parametro aggiun¬ 
to al processoer, il che permette di testarne il funzionamento. Per questo motivo 
non si è ancora resa necessaria la creazione di tutti i controlli nelhinterfaccia vera e 
propria, tranne nel caso dei pulsanti Learn che non rappresentano nessun parametro 
nel motore e sono attivabili solo tramite la GUI. Da notare che, allo stato attua¬ 
le, senza di questi il plughi non potrebbe essere messo in funzione, poiché si ricorda 
che nessun suono può essere innescato finché non gli si assegna una nota di riferimento. 

La classe, definita tra i due file PluginEditor. h e PluginEditor. cpp, è derivata 
da AudioProcessorEditor [1], per cui bisogna fornire l’implementazione dei metodi 
paint() e resizedO. Se si vogliono creare degli oggetti Slider o Button, è neces¬ 
sario che l’editor derivi anche dai rispettivi Listener [2], I listener sono usati dai 
vari Component per comunicare i propri cambiamenti di valore al motore. Anche qui 
vi sono dei metodi astratti per i quali bisogna eseguire l’override, in particolare il me¬ 
todo buttonClickedO per la classe Button: : Listener, che verrà presto analizzato 
in dettaglio. Per Slider: : Listener si devono fornire allo stesso modo 3 metodi, 
ma fortunatamente possono essere lasciati vuoti poiché il framework si occupa già in 
automatico di espletare le loro funzioni, e perciò non verranno citati. 

Questo grazie alla classe SliderAttachment [3] che crea una connessione tra uno 
Slider ed un parametro salvato nclLAudioProcessorValueTreeState e ne gesti¬ 
sce i cambiamenti in maniera biunivoca. Stessa cosa succede per quanto riguarda il 
ButtonAttachment, ma a differenza degli slider, i bottoni richiedono una particolare 
implementazione - fornita in buttonClickedO - poiché devono attivare funzioni spe¬ 
cifiche come Mute e Learn. Un’altra classe dalla quale è stata derivata DrumEditor è 
Timer [4], che serve alla GUI per auto-aggiornarsi allo scadere di un dato tempo. Il 
metodo virtuale puro in questo caso è timerCallbackO, chiamato allo scadere del 
timer stesso e anch’esso visto nel dettaglio in seguito. 
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// PluginEditor.h 
#pragma once 

#include ./JuceLibraryCode/JuceHeader.h" 

#include ./core/PluginProcessor.h" 

class DrumProcessor; 

typedef AudioProcessorValueTreeState::SliderAttachment SliderAttachment; // [3] 
typedef AudioProcessorValueTreeState::ButtonAttachment ButtonAttachment; 

class DrumEditor : public AudioProcessorEditor, // [1] 
public Slider::Listener, 
public Button::Listener, // [2] 

public Timer // [4] 

{ 

public : 

DrumEditor(DrumProcessorfe parent, AudioProcessorValueTreeState& vts); 
void paint (Graphics#;) override; 
void resizedO override; 

H ... 


Nello header sono state implementate dal sottoscritto delle funzioni custom di inizia- 
lizzazione per i vari componenti, in modo da non ingombrare spazio nel file sorgente, 
e soprattutto per semplificare la creazione dei canali. Questi metodi, riportati qui 
sotto, vengono invocati da initChannel () che si occupa di inizializzare un intero 
canale. 

// PluginEditor.h 

void initLabel(Label& label) 

{ 

addAndMakeVisible(label); 

label.setFont(Font(18.OOf, Font ::plain).withTypefaceStyle ("Regular ")); 
label.setJustificationType(Justification::centred); 
label.setEditable (false , false, false); 

label.setColour(TextEditor::textColourld, Colours::black); 

label.setColour(TextEditor: :backgroundColourld, Colour(0x00000000)); 

} 

void initSlider(Slider& slider, Slider::SliderStyle style) 

{ 

addAndMakeVisible(slider); 
slider.setSliderStyle(style); 

slider.setTextBoxStyle(Slider::TextBoxBelow, false, 80, 20); 
slider .addListener(tliis) ; 

> 
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void initButton(Button& button) 

{ 

addAndMakeVisible(button); 
button.addListener (tbis) ; 


All’inizio dell’esecuzione il processore - se hasEditorO restituisce true - crea l’istan¬ 
za di DrumEditor attraverso il metodo createEditor(), passandogli un riferimento 
a sè stesso e ai parametri. NeH’implementazione della classe dunque, per prima cosa 
si inzializzano l’editor stesso, il processore che lo ha creato e i parametri che dovrà 
modificare [5]. All’interno del costruttore viene fatto partire il timer [6], che chiamerà 
il metodo timerCallbackO ogni 100 millisecondi. 

Ora si è pronti alla creazione dei canali: per ognuno vengono presi i riferimenti 
ai rispettivi oggetti [7], i quali sono tutti passati come argomenti a initChannel () 
[8] che li utilizza per creare il canale. L’operazione si ripete per ognuno di essi fino 
ad arrivare al Master. Infine viene impostata la risoluzione (in pixel) della finestra 
principale [9]. 

// PluginEditor.cpp 

DrumEditor::DrumEditor (DrumProcessor& parent, AudioProcessorValueTreeState& vts) 

: AudioProcessorEditor (parent) 

, processor (parent) 

, valueTreeState(vts) // [5] 

{ 

startTimer(100); // [6] 

auto index = 0; 

// Canale 1 

auto name = processor.outputs[index]; 

auto curGroup = &groupl; 

auto curLevelLabel = ÈlevelLabell; 

auto curPanLabel = &panLabell; 

auto curLevelSlider = ÈlevelSliderl; 

auto curPanSlider = fepanSliderl; 

auto curMuteButton = femuteButtonl; 

auto curSoloButton = ÈsoloButtonl; 

auto curLearnButton = femidiLearnButtonl; 

auto curLevelAttach = levelAttachmentl.get(); 

auto curPanAttacb = panAttachmentl.get(); 

auto curMuteAttach = muteAttachmentl.get(); 

auto curSoloAttach = soloAttachmentl.get(); 

auto curLearnAttach = midiLearnAttachmentl.get(); // [7] 
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initChannel (vts, name, ++index, curGroup, curLevelLabel, curPanLabel, // [8] 
curLevelSlider, curPanSlider, curMuteButton, curSoloButton, curLearnButton, 
curLevelAttach, curPanAttach, curMuteAttach, curSoloAttach, curLearnAttach); 

// Canale 2 

Il ... 

Il Master 

name = "Master"; 
curGroup = fonasterGroup; 
curLevelLabel = &masterLevelLabel; 
curPanLabel = fanasterPanLabel; 
curLevelSlider = femasterLevelSlider; 
curPanSlider = fanasterPanSlider; 
curMuteButton = &masterMuteButton; 
curSoloButton = nullptr; 
curLearnButton = nullptr; 

curLevelAttach = masterLevelAttachment.get(); 
curPanAttach = masterPanAttachment.get(); 
curMuteAttach = masterMuteAttachment.get(); 

initChannel(vts, name, ++index, curGroup, curLevelLabel, curPanLabel, 

curLevelSlider, curPanSlider, curMuteButton, curSoloButton, curLearnButton, 
curLevelAttach, curPanAttach, curMuteAttach, curSoloAttach, curLearnAttach); 

setSize (1000, 600); // [9] 

> 


3.6.1 II metodo initChannel() 

Questo metodo custom è stato ideato dal sottoscritto per rendere la creazione dei 
canali il più ordinata possibile, infatti grazie a esso si evita di inserire nel costruttore 
tutte le singole istruzioni per i vari componenti, lasciando solo la chiamata al metodo 
come appena visto. Esso accetta come argomenti il riferimento ai parametri nel pro¬ 
cessore (che servirà per collegarli ai vari ‘attachment’), il nome del canale, il suo indice, 
i puntatori agli oggetti che deve inizializzare e quelli ai loro attachment. Tutti questi 
argomenti sono usati per configurare i vari aspetti di ogni componente, attraverso 
chiamate ai metodi del tipo initSliderO o simili [1], e nel caso anche ad ulteriori 
metodi default per l’impostazione di determinati valori specifici per un tipo di oggetto 
(ad esempio a setRangeO vengono passati argomenti diversi per gli slider di volume 
e pan, allo stesso modo setButtonText() cambierà in base al ruolo del bottone). 
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Ogni componente così generato - tranne group e label, poiché non controllano alcun 
parametro - viene corredato dal suo attachment: attraverso l’operatore new si crea un 
nuovo puntatore all’attachment, il quale richiede, come argomenti per la propria crea¬ 
zione, un riferimento all’AudioProcessorValueTreeState e l’identihcativo del para¬ 
metro [2]: questo sarà utilizzato per collegare V attachment, e quindi il componente a 
cui esso fa riferimento, al parametro precedentemente creato da DrumProcessor. Da 
notare che è necessario passare come ID esattamente la stringa contenente l’identih- 
cativo scelto, la quale viene costruita dinamicamente in maniera simile a quanto visto 
nel metodo createParameters (). 

Dopo che tutti i componenti sono stati creati e collegati ai rispettivi parametri, 
essi vengono aggiunti come 'figli’ del GroupComponent del quale fanno parte [3]. In 
questo modo, come si vedrà meglio in seguito, sarà possibile riferirsi al componente 
padre per le operazioni di disegno vero e proprio dei canali, invece che ricavare le 
misure di riferimento dalla finestra generale. 


// PluginEditor.cpp 

void DrumEditor: :initChannel(AudioProcessorValueTreeState& vts, 

String& channelName, 
int index, 

GroupComponent* group, 

Label* levelLabel, 

Label* panLabel, 

Slider* levelSlider, 

Slider* panSlider, 

Button* muteButton, 

Button* soloButton, 

Button* midiLearnButton, 

SliderAttachment* levelAttachment, 
SliderAttachment* panAttachment, 
ButtonAttachment* muteAttachment, 
ButtonAttachment* soloAttachment, 
ButtonAttachment* midiLearnAttachment) 


String componentlD, paramID, title; 
componentlD = static_cast<String> (index); 
title.clear(); 

title << "#" << componentlD << " << channelName; 

// Group 

addAndMakeVisible(group); 
group->setName(channelName); 
group->setText(title); 

group->setTextLabelPosition(Justification::centred); 
group->setComponentID(componentlD); 

// Labels 

initLabel(*levelLabel); 
initLabel(*panLabel); 
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levelLabel->setText("Level", dontSendNotification); 
panLabel->setText( "Pan" , dontSendNotification); 

// Level Slider 

initSlider(*levelSlider, Slider::LinearVertical); // [1] 
levelSlider->setRange(0, 1, 0); 

levelAttachment = new SliderAttachment // [2] 

(vts, paramID << "p" << channelName << "Level", *levelSlider); 

paramlD.clear(); 

// Pan Slider 

initSlider(*panSlider, Slider::LinearHorizontal); 
panSlider->setRange(-50.0, 50.0, 0.01); 
panAttachment = new SliderAttachment 

(vts, paramID « "p" << channelName << "Pan", *panSlider); 

paramID.clear(); 

// Mute Button 
initButton(*muteButton); 
muteButton->setButtonText(TRANS ("M") ); 
muteAttachment = new ButtonAttachment 

(vts, paramID << "p" << channelName << "Mute", *muteButton); 

paramID.clear(); 

// Solo Button 
if (soloButton != nullptr) { 
initButton(*soloButton); 
soloButton->setButtonText(TRANS ("S") ); 
soloAttachment = new ButtonAttachment 

(vts, paramID << "p" << channelName << "Solo", *soloButton); 

paramID.clear(); 

} 

// Learn Button 

if (midiLearnButton != nullptr) { 
initButton(*midiLearnButton); 

midiLearnButton->setButtonText(TRANS( "Learn" )); 
midiLearnAttachment = new ButtonAttachment 

(vts, paramID << "p" « channelName « "Learn", 
♦midiLearnButton); 

} 

group->addChildComponent(levelLabel, -1) ; 

group->addChildComponent(levelSlider, -1); 
group->addChildComponent(panLabel, -1); 

group->addChildComponent(panSlider, -1); 

group->addChildComponent(muteButton, -1); 
if (soloButton != nullptr) 

group->addChildComponent(soloButton, -1); 
if (midiLearnButton != nullptr) 

group->addChildComponent(midiLearnButton, -1); // [3] 
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3.6.2 II metodo resized() 

In questo metodo astratto avviene la descrizione di come i canali dovranno effet¬ 
tivamente apparire, e il loro effettivo disegno sulla GUI. Dopo la creazione di un 
componente grafico, esso non può essere visualizzato se prima non viene invocato 
il metodo setBoundsO (fornito dal framework) che ne descrive il posizionamento 
all’interno dell’interfaccia. Analogamente a quanto visto prima, queste chiamate so¬ 
no state spostate in drawChannel(), mentre qui vengono presi i riferimenti ai vari 
componenti [1] per poi essere passati come argomento al metodo [2], 

La variabile start [3], anch’essa passata come argomento a drawChannel(), con¬ 
tiene il punto dal quale iniziare a disegnare il primo canale, ovvero l’angolo in alto 
a sinistra del gruppo; quando il primo canale è stato disegnato, start viene incre¬ 
mentato di una quantità uguale alla larghezza del canale stesso [4], in modo che il 
successivo non si sovrapponga a quello appena disegnato. Le operazioni sono ripetute 
per tutti i canali fino ad arrivare al Master, con il quale si conclude il metodo. 

// PluginEditor.cpp 
void DrumEditor: :resizedO 
{ 

auto start = startingPoint; // [3] 

// Canale 1 

auto curGroup = &groupl; // [1] 

auto curLevelLabel = fclevelLabell; 

auto curPanLabel = &panLabell; 

auto curLevelSlider = ÈlevelSliderl; 

auto curPanSlider = fepanSliderl; 

auto curMuteButton = ftmuteButtonl; 

auto curSoloButton = ÈsoloButtonl; 

auto curLearnButton = ftmidiLearnButtonl; 

drawChannel(start, curGroup, curLevelLabel, curPanLabel, curLevelSlider, 
curPanSlider, curMuteButton, curSoloButton, curLearnButton); // [2] 

start += curGroup->getWidth(); // [4] 

// Canale 2 

// ... 

// Master 

curGroup = fonasterGroup; 
curLevelLabel = &masterLevelLabel; 
curPanLabel = fonasterPanLabel; 
curLevelSlider = fanasterLevelSlider; 
curPanSlider = &masterPanSlider; 
curMuteButton = &masterMuteButton; 

drawChannel(start, curGroup, curLevelLabel, curPanLabel, curLevelSlider, 
curPanSlider, curMuteButton, curSoloButton, curLearnButton); 

> 
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3.6.3 II metodo drawChannel() 

Le invocazioni a setBoundsO sono il compito principale di questo metodo, oltre a 
ovvi vantaggi di leggibilità del codice. Esso è stato sviluppato dal sottosritto insieme 
a initChannel (). Il metodo disegna un canale utilizzando gli argomenti che gli 
vengono passati durante la chiamata vista nel paragrafo precedente, cioè partendo 
dal punto startX e con alLinterno i vari componenti. Per prima cosa vengono create 
le variabili con le lunghezze di riferimento, ovvero le larghezze e le altezze che ogni 
gruppo dovrà assumere, e quelle per i vari componenti [1], Nel caso dei bottoni di 
Mute e Solo, la misura è fissata a 50 pixel per 50, mentre per gli altri componenti le 
dimensioni dipenderanno da quelle del gruppo al quale fanno riferimento [2], il quale 
a sua volta dipende dalla finestra principale [3]. 

// PluginEditor.cpp 

void DrumEditor: :drawChannel (int startX, 

Componente group, 

Componente levelLabel, 

Componente panLabel, 

Componente levelSlider, 

Componente panSlider, 

Componente muteButton, 

Componente soloButton, 

Componente midiLearnButton) 

{ 

auto windowWidth = getWidthO - 30; 
auto windowHeight = getHeightO - 30; 

auto groupWidth = windowWidth / (processor.maxMidiChannel +1); // [3] 
auto groupHeight = windowHeight; 
auto buttonWidth = 50; 
auto buttonHeight = 50; 

auto labelHeight =50; // [1] 

auto groupStartX = startX; 
auto groupStartY = startingPoint; 
auto blankSpace = 20 ; 

// Disegna i componenti 
group->setBounds( 
groupStartX, 
groupStartY, 
groupWidth, 
groupHeight 

); 

panLabel->setBounds( 

panLabel->getBoundsInParent().getXO, 
panLabel->getBoundsInParent().getY() + 5, 
panLabel->getParentWidth(), 
labelHeight + 20); 


// x 

// y 

// larghezza 
// altezza 
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panSlider->setBounds( 

panSlider->getBoundsInParent(),getX(), 

panSlider->getBoundsInParent(),getY() + panLabel->getHeight(), 
panSlider->getParentWidth() , // [2] 

50) ; 

muteButton->setBounds( 

muteButton->getBoundsInParent().getCentreXO + blankSpace, 
blankSpace + panSlider->getY() + panSlider->getHeight(), 
buttonWidth, 
buttonHeight) ; 
soloButton->setBounds( 

muteButton->getX() + buttonWidth - blankSpace/2, 
blankSpace + panSlider->getY() + panSlider->getHeight(), 
buttonWidth, 
buttonHeight); 
midiLearnButton->setBounds( 

midiLearnButton->getBoundsInParent().getXQ, 
blankSpace + muteButton->getY() + muteButton->getHeight(), 
midiLearnButton->getParentWidth(), 
buttonHeight); 
levelLabel->setBounds( 

levelLabel->getBoundsInParent(),getX(), 

blankSpace + midiLearnButton->getBoundsInParent().getY() + 
midiLearnButton->getHeight(), 
levelLabel->getParentWidth(), 
labelHeight); 
levelSlider->setBounds( 

levelSlider->getBoundsInParent(),getX(), 

levelLabel->getBoundsInParent().getY() + levelLabel->getHeight(), 
levelSlider->getParentWidth(), 
levelSlider->getParentHeight() / 3); 


3.6.4 II metodo timerCallback() 

Il presente metodo ha l’effetto di ridisegnare l’intera GUI allo scadere di un tempo 
dato, nel nostro caso ogni 100 millisecondi. Questo, come si può intuire, viene at¬ 
tuato nella chiamata a repaintO [1], Nonostante non fosse indispensabile per il 
funzionamento del programma, con questa strategia è stato possibile stendere le basi 
per lo sviluppo di una GUI più complessa. Comunque il motivo pratico per cui è 
stato implementato è che, all’attivazione del pulsante di Learn, la stringa che appare 
sul bottone cambia da “Learn” a “Learning...”, in modo da indicare all’utente che il 
plugin è entrato in stato di attesa di input. Il comportamento atteso è che una volta 
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premuta la nota che si vuole mappare, il bottone torni nella condizione di default. 
Questo non può essere fatto senza un timer, poiché il cambiamento di stato del bot¬ 
tone è influenzato da condizioni interne al motore e non riguardanti hinterfaccia. 
In questa maniera quindi, allo scadere del tempo assegnato, la GUI ricontrolla lo 
stato di isMidiLearning per ogni canale [2] e, nel caso restituisca false, modifica il 
bottone corrispondente riscrivendovi la stringa di default e reimpostandone lo stato 
a false. [3]. Tutto questo non dev’essere fatto troppo spesso, altrimenti potrebbero 
sorgere dei problemi nelhutilizzo delle risorse (in particolare la CPU), specialmente 
quando l’interfaccia diventerà più complessa. Prendendo spunto dal relativo tuto¬ 
ria! ufficiale di JUCE, è stato scelto un tempo di 100 millisecondi poiché ritenuto 
abbastanza lungo per i tempi di calcolo, e abbastanza corto per la percezione umana. 

// PluginEditor.cpp 

void DrumEditor: :timerCallbackO 

{ 

repaintO; // [1] 

if (!processor.synth[0]->isMidiLearning) // [2] 

{ 

midiLearnButtonl.setButtonText(TRANS ("Learn") ); 

midiLearnButtonl.setToggleState (false , dontSendNotification); // [3] 

> 

if (! processor.synth[1]->isMidiLearning) 

{ 

midiLearnButton2.setButtonText(TRANS ("Learn") ); 

midiLearnButton2.setToggleState (false , dontSendNotification); 

> 

// ... 

> 


3.6.5 II metodo buttonClicked() 

L’ultimo metodo analizzato in questo elaborato è buttonClickedO, anch’esso virtua¬ 
le puro, il quale viene invocato qualdo si preme un qualsiasi bottone. Al suo interno, 
ogni bottone è posto all’interno di istruzioni condizionali, in modo da poter decidere 
le azioni da intraprendere per ognuno. Inizialmente sono gestiti i bottoni di Mute, 
poi quelli di Learn: i primi sono posti dentro semplici if e, nel caso in cui il bottone 
premuto sia uno di questi, ognuno chiamerà setMuteEnabledO nel processore per il 
canale corrispondente [1]. 

I pulsanti ‘Learn’ funzionano alla stessa maniera, ma in modalità esclusiva (se su 
un certo canale viene attivata la modalità, essa non può essere attivata su nessun 
altro canale) a differenza di quelli del muto che sono fra loro indipendenti. Per questo 
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motivo nelle istruzioni dei pulsanti ‘Learn’ è stata aggiunta l’etichetta else. Qui di 
seguito si allega un esempio riguardante il primo canale, gli altri sono da ritenersi 
trattati in modo analogo. Ovviamente sul Master non c’è necessità della funzione di 
MIDI Learn. 


// PluginEditor.epp 

void DrumEditor::buttonClicked(Button* button) 

{ 

int i = 0; 

// Muto 

if (button == fanuteButtonl) 

processor.setMuteEnabled(muteButtonl.getToggleStateO, i); // [1] 
i++; 

if (button == &muteButton2) 

processor.setMuteEnabled(muteButton2.getToggleState(), i); 
i++; 

n ... 

if (button == fanasterMuteButton) 

processor.setMuteEnabled(masterMuteButton.getToggleStateO, -1); 

// Learn 

else if (button == &midiLearnButtonl) 

{ 

button->setToggleState (true , dontSendNotification); 
button->setButtonText(TRANS ("Learning... ")) ; 
processor.setLearnFromMidi (true , 0); 

} 

// ... 




Capitolo 4 
Testing 


DrumSampler è stato testato su Windows 10 all’interno di AudioPluginHost e nella 
DAW Ableton Live 9.1.7, in formato VST2 e VST3; la compilazione degli altri formati 
è lasciata a sviluppi futuri. L’utilizzo delle risorse è molto moderato come del resto 
ci si aspettava, visto che sono attivi solamente dne canali con 8 suoni per uno. Per 
questo motivo nei test effettuati ci si è giusto accertati che i valori di utilizzo di CPLT 
e RAM non fossero anomali. 

Il testing del programma è stato fatto di pari passo con l’implementazione delle sue 
funzionalità e ciò è stato possibile grazie agli strumenti messi a disposizione da JUCE 
e Visual Studio: senza l’anteprima dei parametri sarebbe stato necessario implemen¬ 
tare tutti i controlli nella GUI per poter testarne il funzionamento all’interno del 
motore. L’ambiente di sviluppo di Visual Studio poi mette a disposizione dei punti 
di interruzione che consentono di vedere quali valori assumono le variabili a runtime, 
come mostrato nella pagina seguente (Figura 3). Inoltre è buona norma generale 
testare i metodi man mano che vengono scritti, in modo da poter discriminare più 
facilmente la provenienza di possibili problemi. 

Nell’esempio in figura viene testato il funzionamento del Pan. Prima di tutto, sul¬ 
la GUI, lo slider relativo al Pan del secondo canale è stato mosso a sinistra fino a 
raggiungere il valore -0,5 circa. Poi è stato impostato un punto di interruzione all’in¬ 
terno del metodo renderNextBlockO (alla riga 280) in modo da catturare lo stato 
del plughi appena dopo che le variabili che rappresentano i campioni in uscita (1 ed 
r) sono state moltiplicate per il valore salvato nel puntatore pan (righe 277 e 278). 
Visual Studio non interromperà l’esecuzione del plughi finche non viene suonata una 
nota MIDI (dopo che essa è stata collegata al synth tramite il bottone ‘Learn’). In 
questo caso si è andati avanti fino al quarto blocco del suono in modo da mostrare dei 
valori significativi, altrimenti utilizzando blocchi che riproducono l’attacco iniziale, 
non si sarebbe vista molta differenza tra i due canali. Il valore al quale punta pan è 
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276 




277 

1 *= lgain 

* jmin(1.0f - *pan. 

1.0f); 

278 

r *= rgain 

* jmin(1.0f + *pan. 

1.0f); 

279 
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Figura 3: Esempio di debug in Visual Studio utilizzando un punto d’interruzione 


correttamente passato dalla GUI al motore in quanto, come si può vedere, esso vale 
-0,5 circa invece che 0 come da default. Inoltre questo valore corrisponde a quello 
mostrato sull’interfaccia, la quale non è stata inclusa neirimmagine perchè duran¬ 
te l’interruzione essa viene nascosta. L’effetto della moltiplicazione è quello atteso, 
cioè che i campioni a sinistra hanno ampiezza maggiore di quelli a destra, in parti¬ 
colare il campione 1 assume circa due volte il valore del campione r. Di conseguen¬ 
za anche l’effetto applicato sull’audio percepito è quello atteso. Sono stati eseguiti 
numerosi test come quello appena visto, alcuni riusciti da subito, altri invece che 
hanno portato a migliorare il codice fino ad arrivare a quello mostrato nel capitolo 3. 

A inizio sviluppo si manifestavano dei disturbi impulsivi nella riproduzione dell’u¬ 
nico suono usato come test. Si è pensato che la causa potesse essere il fatto che fosse 
sempre la stessa voce a riprodurre il suono, e ciò ha portato a sviluppare l’attua¬ 
le gestione delle voci multiple, in modo che se una è impegnata nella riproduzione 
ne viene trovata un’altra libera con la quale viene riprodotto il suono. Per assicu¬ 
rarsi che il comportamento delle voci fosse quello corretto è stato creato il metodo 
voicesToLogO , che consente di stampare sul log di Visual Studio il numero della 
nota suonata e la voce che ha riprodotto il suono: 

// DrumSynth.h 

void voicesToLog(int midiNote) 

{ 

int voicelndex; 

auto numVoices = getNumVoices(); 

String msg; 
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for (int i = numVoices - 1; i >= 0; i—) 

{ 

voice = voices[i]; 

auto voiceActive = voice->isVoiceActive(); 
if (voiceActive) { 
voicelndex = i; 

msg << "voice: " << voicelndex << ", startNote: " << midiNote << "\n"; 

Logger::getCurrentLogger()->writeToLog(msg); 

break; 

> 

> 

> 


Il metodo cerca una voce attiva nell’array delle voci, e nel caso la trovi stampa il suo 
indice insieme alla nota MIDI che è stata suonata, quindi esce dal ciclo. La ricerca 
viene fatta partendo dall’ultima posizione dclharray, altrimenti nel caso vi fossero più 
voci attive in un dato momento, il metodo stamperà sempre la prima e non si saprà 
mai qual’è l’ultima attiva. Così facendo invece, si è certi che se viene stampata ad 
esempio la voce con indice 1, anche la voce 0 sarà implicitamente attiva, poiché il 
metodo startVoiceO dà sempre in carico la riproduzione alla prima voce libera. In 
base a quanto riportato nel log durante l’esecuzione, le voci hanno un comportamento 
anomalo, come mostrato in Figura 4; 


Output 





▼ ? X 

Mostra output di: Debug 


- 


voice: 

0 , 

startNote: 

72 


▲ 

voice: 

0 , 

startNote: 

72 



voice: 

0 , 

startNote: 

72 



voice: 

1, 

startNote: 

72 



voice: 

0 , 

startNote: 

72 



voice: 

0 , 

startNote: 

72 



voice: 

1, 

startNote: 

72 



voice: 

1, 

startNote: 

72 




Figura 4: L’output del metodo voicesToLogQ visualizzato sul log di Visual Studio 
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Le linee azzurre sono state inserite per migliore comprensione. Le prime due ri¬ 
ghe sono stampate in seguito alla ricezione di due Note On distanti nel tempo fra 
loro: come atteso, la voce che riproduce il suono è in tutti e due i casi la prima 
ncH’array (avente indice zero), poiché il secondo Note On viene ricevuto quando il 
suono ha esaurito la sua durata. Nelle tre righe successive invece, la seconda nota è 
suonata subito dopo la prima e, come previsto, viene riprodotta dalla seconda voce 
(con indice 1). Se si attende che questa si esaurisca per poi suonare un’altra nota, 
la voce incaricata alla sua riproduzione è di nuovo la prima; anche qui il compor¬ 
tamento è quello atteso. Se poi, invece che attendere, si suona subito la terza nota 
(si suonano cioè tre note in veloce sequenza), ci si aspetterebbe che fosse riprodotta 
dalla voce con indice 2. Invece, come mostrato nelle ultime tre righe, quella attiva è 
sempre la voce 1: ciò rivela un comportamento anomalo nella gestione interna delle 
voci ed è causa di possibili clip nell’audio generato, dal momento che una stessa voce 
è improvvisamente costretta a interrompere la riproduzione di un suono per iniziarne 
un altro. 

Sono inoltre presenti altri bug o porzioni di codice poco efficienti in alcune delle fun¬ 
zionalità implementate. Il problema più grosso è stato riscontrato nella gestione dei 
livelli nei canali: ad esempio quando viene attivato Mute sul primo canale (o sul Ma¬ 
ster) esso funziona come dovrebbe, ma se lo si attiva su un canale diverso dal primo, 
l’effetto è quello di mutare tutti i canali precedenti; lo stesso avviene se si modifica uno 
slider diverso dal primo. Questo accade perchè la chiamata a buffer.applyGainO 
moltiplica per currentChannelGain tutti i campioni nel buffer generale, invece che 
farlo sul buffer relativo ad un solo synth. Così quando il canale preso in considerazione 
è diverso dal primo, il livello viene applicato a tutti i canali che hanno riempito il buffer 
hno a quel momento. Un tentativo di risoluzione è stato quello di rendere condizionale 
la chiamata synth [busNr] . renderNextBlockO all’interno di una if, ma i messaggi 
MIDI vengono passati attraverso questa invocazione e così facendo nessun Note On 
potrà innescare alcun suono. Per gli stessi motivi anche lo sviluppo della funzione 
di Solo è stato lasciato in sospeso, poiché coinvolta nella stessa porzione di codice. 

Una possibile soluzione può essere quella di creare un buffer temporaneo per ogni 
synth, il quale viene riempito condizionalmente al fatto che il synth sia in Mute, Solo, 
o nessuno dei due. Lina volta fatto questo sarà possibile riempire il buffer di uscita 
con i synth selezionati. Un’altra soluzione simile prevede sempre un buffer tempora¬ 
neo che viene riempito da ogni synth, e secondo le stesse condizioni sopracitate gli 
viene applicato il rispettivo currentChannelGain. La differenza tra le due è che la 
seconda è più coerente con il comportamento di un vero mixer analogico, il quale 
applica un livello sull’audio in uscita mentre il segnale in ingresso viene mantenuto 
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al suo interno. In questo senso ogni canale riempirà il proprio blocco a prescinde¬ 
re (permettendo così a renderNextBlockO di inviare i messaggi MIDI ai synth), 
in seguito questo blocco può essere aggiunto al buffer generale dopo che gli è stato 
applicato il rispettivo currentChannelGain. La prima soluzione ha il vantaggio di 
essere meno onerosa per la memoria ma sembra la strada meno praticabile dal punto 
di vista concettuale, sempre per il problema di dover rendere condizionali le chiamate 
a renderNextBlockO. 

Al di fuori di questi problemi, in linea generale il plughi funziona come ci si aspet¬ 
tava. Tutti i parametri fin’ora implementati sono stati testati utilizzando lo schema 
visto nell’esempio a inizio capitolo, e in base a tali test risultano effettivamente fun¬ 
zionanti. I parametri Level, Pan, Mute e Learn svolgono correttamente il passaggio 
ai rispettivi puntatori implementati nel motore, che li applica come atteso all’audio 
generato, al di là dei problemi nella gestione del mixaggio dei synth. Questo accade 
sia se essi vengono modificati dall’anteprima dei parametri che dalla GLII principale 
(si ricorda che il Learn per ora è attivabile solo da quest’ultima). Intrinsecamente 
il fatto che, muovendo uno slider sull’anteprima, si modifichi in automatico il con¬ 
trollo corrispondente sulla GUI (e viceversa), indica che gli attachment implementati 
nella GUI interagiscono correttamente coi loro listener. Anche il tuning, non ancora 
inserito nell’interfaccia grafica, è stato testato tramite l’anteprima ed il risultato è 
stato positivo per entrambi i parametri. Coarse può modificare l’altezza del suono 
portandolo fino a 3 ottave in alto o altrettante in basso, mentre Fine sposta la nota 
fissata da Corse di massimo un semitono sopra o sotto. 



Capitolo 5 

Conclusioni e sviluppi futuri 


Nonostante l’ambiziosità e le difficoltà del progetto gran parte dei risultati previsti 
nel breve tempo disponibile sono stati raggiunti. Durante la progettazione iniziale 
il tempo richiesto per il raggiungimento di un programma completo e aderente alle 
specifiche è stato stimato ad un anno; infatti sono ancora molti gli aspetti che vanno 
affrontati e sviluppati. Oltre alla risoluzione dei problemi appena analizzati, il primo 
di questi aspetti è sicuramente 1’implementazione di un inviluppo di ampiezza AHD 
(Attack, Hold, Decay) per poter agire ancora più a fondo sui suoni generati. Esso 
è già incluso nella classe juce: :ADSR ma solo da JUCE 5.4 in poi: questo è uno 
dei motivi che hanno spinto ad aggiornare il framework. La classe implementa un 
inviluppo di tipo ADSR (Attack, Decay, Sustain, Release) applicabile a tutti i tipi di 
suono e adatto in particolare per gestire l’ampiezza dei suoni di lunga durata. Nel 
caso specifico dei suoni di batteria, che per la maggior parte hanno breve durata, 
questo tipo di inviluppo è superfluo e andrà adattato in modo da comportarsi come 
uno di tipo AHD. Ovviamente anche lo sviluppo dei rispettivi controlli sulla GUI 
andrà realizzato di pari passo. 

Un altro importante aspetto da affrontare è la coerenza del plughi con la libreria 
dalla quale carica i campioni: essa ha una struttura gerarchica fissata, come mostrato 
nel grafico in Figura 5. I file sono organizzati in cartelle e sottocartelle che riprodu¬ 
cono questa gerarchia. Il plughi dovrebbe caricare un intero kit suonato con un certo 
oggetto (es. il kit Sonor Designer suonato con le bacchette in legno), nel quale per 
ogni pezzo della batteria (es. Sonor Designer Snare 14x6.5) sono presenti più arti- 
colazioni (Hit, Rimshot, Sidestick ...) che saranno innescate da diverse note MIDI. 
La funzione di Learn quindi dovrebbe permettere di mappare ogni articolazione su 
una diversa nota. All’interno di ogni articolazione vi sono le cartelle con i suoni in 
formato wav, dove ogni cartella raggruppa i suoni registrati da un unico microfono 
(Snare top/bottom, Room L/R, Overhead L/R ...). Il suono innescato da una certa 
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Figura 5: Struttura gerarchica della sample library 


nota dovrà essere quindi la somma dei suoni provenienti dai vari microfoni, sia quelli 
principali in riferimento al pezzo (Snare top/bottom ) sia i possibili rientri in altri 
microfoni vicini, come gli Overhead. Il plughi dovrebbe poi, in base al numero di 
file contenuti in ogni cartella, ricavare il numero di velocity range da creare per poi 
innescare uno alla volta tutti i suoni appartenenti al range in base ad una coda round 
robin; questo renderà lo strumento il più realistico possibile. Inutile sottolineare come 
l’attuale gestione dei file non sia assolutamente adatta a questo scopo, oltre che essere 
poco efficiente e portabile. 

Una caratteristica innovativa del plugin sarà quella di poter controllare singolarmente 
i livelli dei diversi microfoni, compresi i rientri. Unitamente alla possibilità di poter 
mandare ogni canale su un’uscita dedicata (la quale dev’essere ancora implementata), 
insieme le due feature permettono un controllo molto dettagliato sul suono generato 
dal plugin, e ne consentono l’utilizzo anche in ambienti professionali, dove la possi¬ 
bilità di gestire ogni microfono separatamente è fondamentale. Dal punto di vista 
della gestione delle informazioni in ingresso quindi (similmente a quanto implemen¬ 
tato fin’ora) il plugin avrà più synth, ognuno corrispondente ad un pezzo (o meglio 
ad un’articolazione) suonabilc, in modo da poter simulare efficacemente l’interazione 
con lo strumento reale. A livello di audio in uscita invece bisognerà implementare 
un mixer virtuale con un canale per ogni pezzo. All’interno di ognuno, a seconda 
di quanti microfoni principali vengano trovati nella libreria, sarà presente un sotto¬ 
canale per ogni microfono; ogni canale o sottocanale avrà i controlli per i microfoni 
contenenti i propri rientri. Oltre a simulare lo strumento in maniera più realistica 
possibile quindi, si dovrà anche riprodurre virtualmente la microfonazione adottata 
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per la sua ripresa, in modo da fornire un’interfaccia familiare sia al batterista sia al 
fonico che lavora sul mix. Infine ogni canale dovrà avere una funzione di inversione 
della polarità, in modo da poter compensare eventuali disturbi causati da frequenze 
in controfase. Nel Master invece si dovrà implementare un inversione dei canali Left 
e Right, in modo da poter cambiare la prospettiva percepita dal punto di vista del 
batterista o dell’ascoltatore. 

Ovviamente il raggiungimento di un tale obbiettivo nei tempi del tirocinio è stato 
ritenuto impensabile fin dal suo inizio. Pertanto considerando la pressoché inesisten¬ 
te conoscenza tecnica iniziale - sia di C++ che di JUCE - da parte del sottoscritto, e i 
tempi previsti, si ritiene opportuno affermare che i risultati raggiunti siano piuttosto 
soddisfacenti. Per quanto riguarda l’azienda, che puntava allo sviluppo di un moto¬ 
re proprietario, la direzione intrapresa si è rivelata quella corretta e perciò motivo di 
crescita. Per il tirocinante invece, il lavoro svolto è stato fortemente formativo e moti¬ 
vante, sia dal punto di vista professionale che umano, per cui il giudizio sull’esperienza 
è senza dubbio positivo. 
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